| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btmtksdio, btmtkuart: validate WMT event length before struct access
btmtksdio.c and btmtkuart.c cast a received WMT event straight to
struct btmtk_hci_wmt_evt and read its op/flag fields without checking
the event is long enough to contain them, unlike btmtk.c. The
FUNC_CTRL case then further casts to struct btmtk_hci_wmt_evt_funcc
and reads its 2-byte status field, again without a length check.
Firmware that sends a short or malformed WMT event makes both drivers
read past the end of the received SKB.
Mirror btmtk.c: validate the base WMT header with skb_pull_data()
before touching any of its fields, and when a FUNC_CTRL event turns
out to be the short, header-only form (a plain enable/disable ack
with no status word), decode the result from the header's own flag
byte instead (0 = success, otherwise failure).
Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: Fix parent socket leak in iso_conn_ready()
iso_get_sock() returns the parent socket with a reference held, which is
dropped by sock_put() once the child socket has been set up. The error
path taken when iso_sock_alloc() fails only calls release_sock() and
returns, leaking the reference and thus the parent socket itself.
Drop the reference on that path as well. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_qca: Do not write to the serial port after it is closed
hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP
is set (for example, for the WCN399x family). A failed hci_dev_open_sync()
following a successful qca_setup() calls hdev->close() but not
hdev->shutdown(), so the port is closed while power->vregs_on is left true.
qca_serdev_remove() then passes its power->vregs_on test and calls
qca_power_off(), which writes to the closed port unconditionally.
Seen on a WCN3988 by unbinding the driver after a controller failure. The
trace below is from a 7.0.0 based kernel, where qca_power_off() was still
named qca_power_shutdown():
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000038
Call trace:
tty_set_termios+0x50/0x238 (P)
ttyport_set_baudrate+0x84/0xc0
serdev_device_set_baudrate+0x24/0x40
qca_power_shutdown+0x158/0x1fc [hci_uart]
qca_serdev_remove+0x54/0x68 [hci_uart]
serdev_drv_remove+0x1c/0x2c
device_remove+0x4c/0x80
device_release_driver_internal+0x1cc/0x224
device_driver_detach+0x18/0x24
unbind_store+0xb4/0xc0
Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place
it closes the port, before writing to it. The regulator disable is left
unconditional so the controller is still powered down.
The dangling serport->tty that turns this into a use-after-free is
addressed in a separate patch. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: coredump: Quiesce dump work on unregister
hci_devcd_handle_pkt_init() arms dump_timeout and coredump producers
queue dump_rx without holding an hdev reference. Unregister leaves both
works live, so disconnecting during an active dump lets them access hdev
after hci_release_dev() frees it.
Shut down coredump processing during unregister. Close the producer gate
under dump_q.lock before disabling both works, then free the active buffer
and queued packets under hci_dev_lock. Serializing the gate with enqueue
prevents controller-specific workers from adding packets after the final
purge. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btintel_pcie: validate TX skb length in send_sync
btintel_pcie_prepare_tx() copies skb->len bytes into a fixed
BTINTEL_PCIE_BUFFER_SIZE (4096) DMA slot via an unchecked memcpy.
Oversized packets are currently rejected only in
btintel_pcie_send_frame(); any future caller of
btintel_pcie_send_sync() would silently overflow the DMA buffer.
Add the bounds check in btintel_pcie_send_sync() itself, right
before skb_push() and the DMA copy. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained
hci_send_acl(), hci_send_sco() and hci_send_iso() queue hdev->tx_work
unconditionally. They can run from the L2CAP/SCO/ISO socket send path
while hci_dev_close_sync() is draining hdev->workqueue (HCIDEVDOWN
racing with a socket write). Since that queue_work() is not chained
work from the tx_work worker itself, __queue_work() sees the queue
marked __WQ_DRAINING, warns "cannot queue %ps on wq %s", and drops
the work:
WARNING: CPU: 1 PID: 5985 at kernel/workqueue.c:2352 __queue_work
Call Trace:
queue_work_on
l2cap_chan_send
l2cap_sock_sendmsg
...
hci_dev_close_sync() already sets HCI_CMD_DRAIN_WORKQUEUE before
draining, but only hci_cmd_work() and handle_cmd_cnt_and_timer()
check it before queuing. Route the tx_work producers through the
same guard via a shared hci_sched_tx() helper. |
| In the Linux kernel, the following vulnerability has been resolved:
dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg()
In mmp_pdma_prep_slave_sg(), for_each_sg() iterates the scatterlist
putting each entry into 'sg', but the entry length is read from 'sgl'
(the list head) instead of 'sg' (the current entry):
for_each_sg(sgl, sg, sg_len, i) {
addr = sg_dma_address(sg);
avail = sg_dma_len(sgl); /* should be 'sg' */
Consequently 'avail' is always the length of the first entry. For
multi-sg lists this causes out-of-bounds reads when a later entry is
shorter than the first, and silent data loss when it is longer.
Single-sg or uniformly-sized lists happen to mask the issue. |
| In JetBrains TeamCity before 2026.1.3
2025.11.7 kotlin DSL sandbox escape leading to RCE on the server was possible |
| Mattermost versions 11.9.x <= 11.9.0, 11.8.x <= 11.8.4, 11.7.x <= 11.7.7, 10.11.x <= 10.11.22 fail to validate that a property field belongs to the specified run before updating its value which allows an authenticated user with run property-management access to crash the Playbooks plugin via a REST request referencing a property field that belongs to a different run. Mattermost Advisory ID: MMSA-2026-00684 |
| ImageSharp is a 2D graphics library. From 2.1.0 until 4.1.2, the TIFF CCITT Group 4 encoder allocates Width times rowsPerStrip bytes even though T6BitCompressor.CompressStrip can emit encoded row data and two 12-bit end-of-facsimile-block codes beyond that capacity. TiffCcittCompressor.WriteCode performs unchecked writes, and a decode-and-re-encode flow can inherit TiffCompression.CcittGroup4Fax and one-bit metadata from attacker-supplied input. The resulting out-of-bounds writes can corrupt memory and terminate the process. This issue is fixed in version 4.1.2. |
| ImageSharp is a 2D graphics library. From 2.0.0 until 4.1.2, decoding an attacker-supplied 32-bit floating-point TIFF as Image<HalfVector4> and applying HistogramEqualization can produce a non-finite or out-of-range luminance in ColorNumerics.GetBT709Luminance. GrayscaleLevelsRowOperation.Invoke uses the resulting value as an unchecked histogram offset, causing an unsafe out-of-range access and process termination. Adaptive Histogram Equalization and AutoLevel are not affected by this report. This issue is fixed in version 4.1.2. |
| In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mst: move switchdev call outside rcu
This is a follow-up of one of sashiko's pre-existing bug reports.
br_mst_set_state() calls switchdev_port_attr_set() for nonzero MSTIs
while holding rcu_read_lock() which invokes the blocking switchdev
notifier chain and may sleep. Nonzero MSTI changes come from netlink
with rtnl held. Move the switchdev call before entering the rcu section and
assert that rtnl is held.
The call cannot be deferred because netlink needs its error and extack.
Also DSA reads the old bridge MST state during the callback and checks it.
A deferred callback will be late and will see the updated state. |
| In the Linux kernel, the following vulnerability has been resolved:
net: fddi: skfp: fix NULL deref when setting the MAC address while down
skfp_ctl_set_mac_address() calls ResetAdapter() unconditionally, without
checking netif_running(). ResetAdapter() first calls card_stop(), which
sets smc->hw.hw_state to STOPPED, and then mac_drv_clear_tx_queue(),
which walks the two transmit queues:
for (i = QUEUE_S; i <= QUEUE_A0; i++) {
queue = smc->hw.fp.tx[i] ;
...
t = queue->tx_curr_get ;
smc->hw.fp.tx[] is only populated by init_tx(), which is reached from
skfp_open() through init_smt() -> init_fddi_driver() -> init_fplus() ->
init_mac() -> init_tx(). The private area is allocated and zeroed by
alloc_fddidev(), so on an interface that has never been brought up both
queue pointers are still NULL. The hw_state test at the top of
mac_drv_clear_tx_queue() does not catch this, because card_stop() has
just set STOPPED; the function proceeds into the loop and dereferences
NULL. ResetAdapter() does call init_smt() itself, but only after the
queues have been cleared.
Setting the MAC address on a down interface therefore oopses:
ip link set dev fddi0 address 02:00:00:00:00:01
BUG: KASAN: null-ptr-deref in mac_drv_clear_tx_queue+0x68/0x2c0 [skfp]
Read of size 8 at addr 0000000000000010 by task ip/302
Call Trace:
<TASK>
mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b]
netif_set_mac_address+0x1e4/0x2c0
do_setlink+0x684/0x2680
</TASK>
Address 0x10 is the offset of tx_curr_get, the third pointer in
struct s_smt_tx_queue, on 64-bit. mac_drv_clear_rx_queue(), which
ResetAdapter() calls immediately afterwards, dereferences
smc->hw.fp.rx[QUEUE_R1] in the same way behind the same ineffective
hw_state test; the transmit queue merely crashes first. Both are
covered by the guard below.
Skip the adapter reset when the interface is down. dev_addr_set() is
left unconditional, so the new address is still recorded in
dev->dev_addr. Nothing is lost by not resetting the adapter here:
skfp_open() deliberately re-reads the factory address on every open,
read_address(smc, NULL);
eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a);
and the comment above it states this is done to discard exactly such an
address override across a close/open cycle. An address set while the
interface is down could not have survived the following open even
before this change, so the guard removes no working behaviour. Guarding
the hardware side of ndo_set_mac_address() with netif_running() is
established practice; skge_set_mac_address() has done so since commit
2eb3e621c4e0 ("skge: set mac address bonding fix").
Guarding the reset as a whole, rather than NULL-checking the queues, is
also what the rest of the driver expects. After a previous open/close
the queue pointers are stale but non-NULL, so there is no crash, yet
ResetAdapter() goes on to call smt_online() and STI_FBI() ("Enable
Board Interrupts") while skfp_close() has already called free_irq() -
the adapter would be brought back online with no handler installed. The
only other ResetAdapter() caller is skfp_interrupt(), which by
construction runs only while the device is open.
Found by automated driver testing against an emulated SysKonnect FDDI
adapter under a KASAN-enabled 7.0.0 kernel. Triggering it requires
CAP_NET_ADMIN. |
| In the Linux kernel, the following vulnerability has been resolved:
net: bcmgenet: restore the hardware filters on open
bcmgenet_hfb_init() runs INIT_LIST_HEAD() on priv->rxnfc_list, which drops
every rule off the list, and bcmgenet_open() calls it on each ifup. Every
rule the user configured is silently lost:
# ethtool -N eth0 flow-type ether dst $MAC action 0
Added rule with ID 0
# ethtool -n eth0 | grep -c Filter:
1
# ip link set eth0 down && ip link set eth0 up
# ethtool -n eth0 | grep -c Filter:
0
Initialise the lists once at probe and restore the rules on open, as
bcmgenet_resume() already does. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: Use managed KMS polling to fix UAF on unbind
vc4_kms_load() calls drm_kms_helper_poll_init() but the driver provides
no matching drm_kms_helper_poll_fini(). The output poll work stays
scheduled after unbind and runs on the freed drm_device:
# modprobe vc4; rmmod vc4; sleep 10
BUG: KASAN: slab-use-after-free in delayed_work_timer_fn
BUG: KASAN: slab-use-after-free in drm_client_dev_hotplug [drm]
Workqueue: events output_poll_execute [drm_kms_helper]
Allocated by task 171: __devm_drm_dev_alloc
Freed by task 262 (rmmod): drm_dev_put / component_del
Use drmm_kms_helper_poll_init() so polling is finalized with the device,
as other drivers do. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: virt_wifi: don't transfer operstate before register
virt_wifi_newlink() calls netif_stacked_transfer_operstate() before
register_netdevice(). If the lower device is dormant, that queues the
new netdev on lweventlist while it is still uninitialized. If
registration fails after that, for example because of an invalid name
such as "bad/name", free_netdev() immediately frees the object. A
later linkwatch_fire_event() then use-after-frees the list entry.
Move the transfer to after netdev_upper_dev_link(), as macvlan and
ipvlan already do. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: 6fire: fix OOB write from device-reported iso length
usb6fire_pcm_in_urb_handler() sizes each outgoing isochronous packet as
(actual_length - 4) / (in_n_analog << 2) * (out_n_analog << 2) + 4, where
actual_length is the unsigned length the device reported for the matching
IN packet. A packet completed with status 0 and actual_length < 4 wraps
the subtraction to 0x7fffffec; a zero-length isochronous packet is legal
on the bus, and the preceding loop rejects only non-zero status. The sum
reaches memset() on out_urb->buffer, a 4832-byte object from
kcalloc(PCM_MAX_PACKET_SIZE, PCM_N_PACKETS_PER_URB).
Even without the wrap the result is out of bounds: at 88.2/96 kHz the
4-in/6-out scaling turns a full 420-byte IN packet into 628, so eight
packets span 5024 bytes of that buffer. usb_submit_urb() rejects an
over-long descriptor only after the memset() and the
usb6fire_pcm_playback() copy of user PCM data have run.
Guard the subtraction as the sibling usb6fire_pcm_capture() already does,
and limit the frame count to what fits in rt->out_packet_size, the OUT
endpoint's wMaxPacketSize. This bounds total_length by the buffer size
while keeping each packet length aligned to a whole output frame.
BUG: KASAN: out-of-bounds in usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338)
Write of size 18446744073709551456 at addr ffff88802a3d0000 by task vhci_rx/5018
Call Trace:
dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
kasan_report (mm/kasan/report.c:595)
kasan_check_range (mm/kasan/generic.c:186 mm/kasan/generic.c:200)
__asan_memset (mm/kasan/shadow.c:84)
usb6fire_pcm_in_urb_handler (sound/usb/6fire/pcm.c:338)
__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)
usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741)
vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107 drivers/usb/usbip/vhci_rx.c:242)
kthread (kernel/kthread.c:436)
ret_from_fork (arch/x86/kernel/process.c:158)
ret_from_fork_asm (arch/x86/entry/entry_64.S:245)
Allocated by task 10:
__kmalloc_cache_noprof (mm/slub.c:5563)
usb6fire_pcm_init (sound/usb/6fire/pcm.c:560 sound/usb/6fire/pcm.c:595)
usb6fire_chip_probe (sound/usb/6fire/chip.c:133)
usb_probe_interface (drivers/usb/core/driver.c:399)
The buggy address belongs to the object at ffff88802a3d0000
which belongs to the cache kmalloc-8k of size 8192
The buggy address is located 0 bytes inside of
4832-byte region [ffff88802a3d0000, ffff88802a3d12e0)
Kernel panic - not syncing: Fatal exception in interrupt |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: skip PUSH_IDLE when the link was never enabled
msm_dp_display_atomic_enable() returns early when link training fails,
leaving ->power_on false and the main link down.
msm_dp_display_atomic_disable() nevertheless writes DP_STATE_CTRL_PUSH_IDLE
and waits for an idle-pattern completion that cannot arrive, so every failed
enable is followed by "PUSH_IDLE pattern timedout".
Every other step of the teardown is already gated on that flag:
msm_dp_display_disable(), called from .atomic_post_disable(), returns early
on !power_on. The PUSH_IDLE write is the only one that is not, so the
controller's runtime-PM reference is then dropped without the link having
been taken down.
On glymur (Snapdragon X2 Elite) the consequence is not a warning. The SoC
does not survive it: TrustZone force-stops the SOCCP and ADSP remote
processors and the machine resets silently about 50 ms later, with no oops
and no panic. On an ASUS Zenbook A16 (UX3607OA), whose eDP panel does not
currently train, this reproduces without any compositor or GPU involvement:
# eDP enable has already failed with "Failed link training (rc=-104)"
echo 1 > /sys/class/graphics/fb0/blank
[535.645455] === marker ===
[535.694833] qcom_q6v5_pas d00000.remoteproc: fatal error received: \
sys_m_smsm.c:512:TZ force stop
[535.694875] remoteproc remoteproc0: crash detected in soccp: type fatal error
[535.728857] qcom_q6v5_pas 6800000.remoteproc: fatal error received: \
sys_m_smsm.c:783:err fatal notification received from TZ
<SoC reset>
Gate the PUSH_IDLE write on ->power_on so the disable path is consistent
with the rest of the teardown. With this applied the same sequence is
harmless and the machine stays up; without it, it resets every time.
The unconditional write dates back to the original DP driver
(c943b4948b58 ("drm/msm/dp: add displayPort driver support")), but the
surrounding code has been restructured several times since, so no Fixes:
tag is offered.
Note that the eDP link-training failure that exposes this on the A16 is a
separate problem in the glymur eDP PHY and is reported separately; this
change is about not damaging the machine when training fails, for whatever
reason.
Tested on ASUS Zenbook A16 (UX3607OA), Snapdragon X2 Elite Extreme, on
linux-next next-20260803 and next-20260807. The machine has since been
running next-20260807 with this patch as its daily driver.
Patchwork: https://patchwork.freedesktop.org/patch/745167/ |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: set timer->private_data before registering the PCM timer
snd_pcm_timer_init() calls snd_device_register() to link the new
struct snd_timer into the global timer list while it still carries
hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop),
and only afterwards sets timer->private_data = substream.
Once the timer is on the list under register_mutex, a concurrent
reader can already reach it through the same mutex and invoke these
callbacks. /proc/asound/timers does this via c_resolution(), and
snd_timer_open()+snd_timer_start() reach start()/stop() the same way.
All three dereference timer->private_data, which for this brief
window is NULL, giving a NULL-pointer dereference:
substream = timer->private_data;
return substream->runtime ? ... // substream is NULL
Move the private_data/private_free assignment before
snd_device_register() so the timer is never visible on the list
without its private_data set. On the snd_device_register() failure
path, private_free() (snd_pcm_timer_free()) can now run, but it only
does substream->timer = NULL, which is already NULL at that point
since substream->timer is set to the new timer just once, after a
successful registration -- so the failure path stays safe. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs: guard against null kobj name
In the client, if `init_path()` errors, the callee tries to clean up
with `rtrs_clt_close_conns()`. However, this can lead to calling the
event tracing code with `clt_path->kobj->name` being `NULL` and thus
causing a null pointer dereference when trying to copy from it.
This just adds a guard to check that the name is not `NULL` before
copying from it. The server appears to have a similar pattern. |
