CVE-2026-16384
published 2026-07-21CVE-2026-16384: Information disclosure due to uninitialized memory in the Graphics: WebGPU component. This vulnerability was fixed in Firefox 153 and Thunderbird 153.
PriorityP342high7.5CVSS 3.1
AVNACLPRNUINSUCHINAN
EPSS
0.31%
23.5th percentile
Information disclosure due to uninitialized memory in the Graphics: WebGPU component. This vulnerability was fixed in Firefox 153 and Thunderbird 153.
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| elysiajs | elysia | >= 0 < 1.4.26 | 1.4.26 |
| linux | linux_kernel | >= 5.18.0 < 6.1.163 | 6.1.163 |
| linux | linux_kernel | >= 6.13.0 < 6.18.10 | 6.18.10 |
| linux | linux_kernel | >= 6.2.0 < 6.6.124 | 6.6.124 |
| linux | linux_kernel | >= 6.7.0 < 6.12.70 | 6.12.70 |
| mozilla | firefox | < Firefox 153 | Firefox 153 |
| mozilla | firefox | < 153.0.0 | 153.0.0 |
| mozilla | thunderbird | < Thunderbird 153 | Thunderbird 153 |
| mozilla | thunderbird | < 153.0 | 153.0 |
CVSS provenance
nvdv3.17.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
osv7.8HIGH
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
firefox: thunderbird: Information disclosure due to uninitialized memory in the Graphics: WebGPU component
vendor_redhat·2026-07-21·CVSS 7.5
CVE-2026-16384 [HIGH] CWE-824 firefox: thunderbird: Information disclosure due to uninitialized memory in the Graphics: WebGPU component
firefox: thunderbird: Information disclosure due to uninitialized memory in the Graphics: WebGPU component
A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue:
Information disclosure due to uninitialized memory in the Graphics: WebGPU component
Statement: Red Hat Product Security rates the severity of this flaw as determined by the Mozilla Foundation Security Advisory.
Package: firefox (Red Hat Enterprise Linux 10) - Not affected
Package: rhel10/firefox-flatpak (Red Hat Enterprise Linux 10) - Not affected
Package: rhel10/thunderbird-flatpak (Red Hat Enterprise Linux 10) - Not affected
Package: thunderbird (Red Hat Enterprise Linux 10) - Not affected
Package: firefox (Red Hat Enterprise Linux 6) - Not affected
Package
Red Hat
kernel: HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
vendor_redhat·2026-02-14·CVSS 7.8
CVE-2026-23178 [HIGH] CWE-120 kernel: HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
kernel: HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
`i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of data
into `ihid->rawbuf`.
The former can come from the userspace in the hidraw driver and is only
bounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set
`max_buffer_size` field of `struct hid_ll_driver` which we do not).
The latter has size determined at runtime by the maximum size of
different report types you could receive on any particular device and
can be a much smaller value.
Fix this by truncating `recv_len` to `ihid->bufsize - sizeof(__le16)`.
The impact is low since access to hidraw devices
Red Hat
kernel: Linux kernel: Use-after-free in teql queueing discipline can lead to privilege escalation
vendor_redhat·2026-02-04·CVSS 7.8
CVE-2026-23074 [HIGH] CWE-825 kernel: Linux kernel: Use-after-free in teql queueing discipline can lead to privilege escalation
kernel: Linux kernel: Use-after-free in teql queueing discipline can lead to privilege escalation
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Enforce that teql can only be used as root qdisc
Design intent of teql is that it is only supposed to be used as root qdisc.
We need to check for that constraint.
Although not important, I will describe the scenario that unearthed this
issue for the curious.
GangMin Kim managed to concot a scenario as follows:
ROOT qdisc 1:0 (QFQ)
├── class 1:1 (weight=15, lmax=16384) netem with delay 6.4s
└── class 1:2 (weight=1, lmax=1514) teql
GangMin sends a packet which is enqueued to 1:1 (netem).
Any invocation of dequeue by QFQ from this class will not return a packet
until after 6.4s. In the meantime, a second packet is sen
Mozilla
Mozilla Foundation Security Advisory 2026-68: CVE-2026-16384
vendor_mozilla
CVE-2026-16384 Mozilla Foundation Security Advisory 2026-68: CVE-2026-16384
Mozilla Foundation Security Advisory 2026-68
CVE: CVE-2026-16384
Product: Firefox
Impact: high
Fixed in: Firefox 153
Mozilla
Mozilla Foundation Security Advisory 2026-71: CVE-2026-16384
vendor_mozilla
CVE-2026-16384 Mozilla Foundation Security Advisory 2026-71: CVE-2026-16384
Mozilla Foundation Security Advisory 2026-71
CVE: CVE-2026-16384
Product: Thunderbird
Impact: high
Fixed in: Thunderbird 153
GHSA
Information disclosure due to uninitialized memory in the Graphics: WebGPU component.
ghsa_unreviewed·2026-07-21
CVE-2026-16384 [HIGH] CWE-908 Information disclosure due to uninitialized memory in the Graphics: WebGPU component.
Information disclosure due to uninitialized memory in the Graphics: WebGPU component. This vulnerability was fixed in Firefox 153.
GHSA
Elysia has a string URL format ReDoS
ghsa·2026-03-10
CVE-2026-30837 [HIGH] CWE-1333 Elysia has a string URL format ReDoS
Elysia has a string URL format ReDoS
### Impact
`t.String({ format: 'url' })` is vulnerable to redos
Repeating a partial url format (protocol and hostname) multiple times cause regex to slow down significantly
```js
'http://a'.repeat(n)
```
Here's a table demonstrating how long it takes to process repeated partial url format
| `n` repeat | elapsed_ms |
| --- | --- |
| 1024 | 33.993 |
| 2048 | 134.357 |
| 4096 | 537.608 |
| 8192 | 2155.842 |
| 16384 | 8618.457 |
| 32768 | 34604.139 |
### Patches
Patched by 1.4.26, please kindly update `elysia` to >= 1.4.26
Here's how long it takes after the patch
| `n` repeat | elapsed_ms |
| --- | --- |
| 1024 | 0.194 |
| 2048 | 0.274 |
| 4096 | 0.455 |
| 8192 | 0.831 |
| 16384 | 1.632 |
| 32768 | 3.052 |
### Workarounds
1. It's recommended to always
OSV
HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
osv·2026-02-14·CVSS 7.8
CVE-2026-23178 HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
`i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of data
into `ihid->rawbuf`.
The former can come from the userspace in the hidraw driver and is only
bounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set
`max_buffer_size` field of `struct hid_ll_driver` which we do not).
The latter has size determined at runtime by the maximum size of
different report types you could receive on any particular device and
can be a much smaller value.
Fix this by truncating `recv_len` to `ihid->bufsize - sizeof(__le16)`.
The impact is low since access to hidraw devices re
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2026-16384 firefox: thunderbird: Information disclosure due to uninitialized memory in the Graphics: WebGPU component
bugzilla·2026-07-21·CVSS 7.5
CVE-2026-16384 [HIGH] CVE-2026-16384 firefox: thunderbird: Information disclosure due to uninitialized memory in the Graphics: WebGPU component
CVE-2026-16384 firefox: thunderbird: Information disclosure due to uninitialized memory in the Graphics: WebGPU component
Information disclosure due to uninitialized memory in the Graphics: WebGPU component. This vulnerability was fixed in Firefox 153.
Bugzilla
CVE-2026-53196 kernel: USB: serial: io_ti: fix heap overflow in get_manuf_info()
bugzilla·2026-06-25
CVE-2026-53196 [HIGH] CVE-2026-53196 kernel: USB: serial: io_ti: fix heap overflow in get_manuf_info()
CVE-2026-53196 kernel: USB: serial: io_ti: fix heap overflow in get_manuf_info()
In the Linux kernel, the following vulnerability has been resolved:
USB: serial: io_ti: fix heap overflow in get_manuf_info()
get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the
device I2C EEPROM into a buffer allocated with kmalloc_obj(), which
is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes.
The Size field comes from the device and is only validated (in
check_i2c_image()) to make sure the descriptor fits within
TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size.
A malicious USB device can therefore set Size to any value up to 16377,
causing a heap overflow of up to 16367 bytes when plugged into a host
running this driver.
valid_csum() is called after read_rom() an
Bugzilla
CVE-2026-23178 kernel: HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
bugzilla·2026-02-14·CVSS 7.8
CVE-2026-23178 [HIGH] CVE-2026-23178 kernel: HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
CVE-2026-23178 kernel: HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: fix potential buffer overflow in i2c_hid_get_report()
`i2c_hid_xfer` is used to read `recv_len + sizeof(__le16)` bytes of data
into `ihid->rawbuf`.
The former can come from the userspace in the hidraw driver and is only
bounded by HID_MAX_BUFFER_SIZE(16384) by default (unless we also set
`max_buffer_size` field of `struct hid_ll_driver` which we do not).
The latter has size determined at runtime by the maximum size of
different report types you could receive on any particular device and
can be a much smaller value.
Fix this by truncating `recv_len` to `ihid->bufsize - sizeof(__le16)`.
The impact is low since acce
2026-07-21
Published