| 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:
dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel()
When dma_device_put() drops the last reference on chan->device->ref,
dma_device_release() runs and may free the dma_device along with its
channels.
dma_chan_put() then still reads chan->device->owner via
dma_chan_to_owner() for the trailing module_put(). KASAN catches it:
slab-use-after-free in dma_chan_put+0x3e6/0x4c0
Read of size 8 by task insmod/6319
Freed by task 6319:
kfree+0x225/0x470
dma_chan_put+0x395/0x4c0
dmaengine_put+0xf8/0x160
Cache the module owner in dma_chan_put() before the put so the trailing
module_put() does not need chan->device. |
| 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. |
| 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:
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:
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:
netfilter: nft_nat: fully initialise new_addr in netmap setup
nft_nat_setup_netmap() builds the mapped address in an on-stack
union nf_inet_addr. For an IPv4 mapping it writes only the 4-byte .ip
member and the loop runs a single 32-bit iteration, but it then copies
the whole 16-byte union into range->min_addr and range->max_addr, so the
upper 12 bytes reach nf_nat_setup_info() uninitialised.
KMSAN reports an uninit-value in nf_nat_setup_info() reached from
nft_nat_eval(). The IPv6 path fills all 16 bytes and is not affected.
Zero-initialise new_addr. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: only operate on TDLS peers in the TDLS code
ieee80211_tdls_oper() can operate on the AP station, which then
yields various warnings when the AP station is removed then or
at a later point in time after being confused for a TDLS peer.
Always check that the station is a TDLS peer. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: abort chanswitch when leaving a mesh
The code in ieee80211_stop_mesh() leaves CSA active, but leaving
the mesh released the channel context, so the CSA finalize work
crashes:
Oops: general protection fault, probably for non-canonical address
0xdffffc0000000003
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
RIP: 0010:ieee80211_put_srates_elem+0x42/0x640 net/mac80211/util.c:3272
Call Trace:
ieee80211_mesh_build_beacon+0xa83/0x1b50 net/mac80211/mesh.c:1093
ieee80211_mesh_rebuild_beacon+0xc7/0x170 net/mac80211/mesh.c:1147
ieee80211_mesh_finish_csa+0x131/0x210 net/mac80211/mesh.c:1542
ieee80211_set_after_csa_beacon net/mac80211/cfg.c:4085 [inline]
__ieee80211_csa_finalize net/mac80211/cfg.c:4133 [inline]
ieee80211_csa_finalize+0x633/0x1150 net/mac80211/cfg.c:4155
cfg80211_wiphy_work+0x2ab/0x450 net/wireless/core.c:438
Abort the channel switch properly. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't offload TC setup on AP_VLAN interfaces
AP_VLAN interfaces are purely virtual, so don't try to offload
TC setup to drivers. We can't really use the AP interface either
since we may not know it all the time, and it could technically
even change.
Just reject the TC offload so things get done in software. |
| In the Linux kernel, the following vulnerability has been resolved:
IB/IPoIB: Avoid restoring OPER_UP after multicast flush
ipoib_ib_dev_flush_light() temporarily clears IPOIB_FLAG_OPER_UP to
prevent multicast joins while ipoib_mcast_dev_flush() is running, and
restores the flag afterwards if it was previously set.
This restore races with ipoib_ib_dev_down(). If the interface is brought
down while the flush is in progress, ipoib_ib_dev_down() clears
IPOIB_FLAG_OPER_UP, but the flush path may set it again after the device
has already gone down.
Since commit 894021a75291 ("IB/ipoib: Make the carrier_on_task race
aware"), ipoib_mcast_carrier_on_task() relies on IPOIB_FLAG_OPER_UP
being cleared to terminate its rtnl_trylock() retry loop. If the flag is
left set after shutdown, the workqueue retries forever, causing teardown
to deadlock when ipoib_ndo_uninit() waits in destroy_workqueue() while
holding RTNL.
Instead of overloading IPOIB_FLAG_OPER_UP to block multicast joins
during a light flush, introduce a dedicated IPOIB_FLAG_MCAST_FLUSH flag.
Use it together with IPOIB_FLAG_OPER_UP to determine whether multicast
joins are allowed, avoiding the race with device shutdown. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: virt_wifi: free skb when disconnected
When the simulated link is disconnected, virt_wifi_start_xmit() returns
NET_XMIT_DROP without freeing the skb. dev_hard_start_xmit() treats this
return value as consumed, so every packet sent while disconnected leaks its
skb.
Free the skb before returning the drop status. |
| In the Linux kernel, the following vulnerability has been resolved:
net/packet: clear RX owner on VNET header error
Commit 61fad6816fc1 ("net/packet: tpacket_rcv: avoid a producer race
condition") added rx_owner_map and made tpacket_rcv() claim a V1 or V2
ring slot before converting the virtio-net header. If the conversion
fails, the drop path leaves the slot claimed.
With a one-frame TPACKET_V2 ring, an unsupported UDP GSO packet leaves
the only slot unavailable, so the ring also drops the next valid packet.
Clear the ownership bit on this error path. TPACKET_V3 already clears
its block state here. |
| In the Linux kernel, the following vulnerability has been resolved:
dma-buf: Fix silent overflow for phys vec to sgt
In case MMIO size is bigger than 4G and peer2peer DMA goes
through host bridge, we trigger a code path that assigns the
total linked IOVA (which is greater than 4G) to mapped_len.
Previously, `mapped_len` was declared as 32-bit `unsigned int`.
When accumulating `size_t` lengths, this leads to a silent wrap-around.
This truncation causes truncated lengths to be passed to functions
like `fill_sg_entry()`.
Fix this by changing `mapped_len` to `size_t` (64-bit). While
at it, fix similar potential overflow issues in `calc_sg_nents`
by using `check_add_overflow()` for `nents` and using
`unsigned int` for the loop iterator in `fill_sg_entry` to match. |
| In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: check create_singlethread_workqueue() in DCB setup
bnxt_re_init_dcb_wq() ignores a failed allocation. The async DCB
handler later calls queue_work() on the NULL pointer. |
| In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix compat ALLOCSPI request use-after-free
xfrm_state_netlink() builds the ALLOCSPI response with
dump_one_state(), which already calls alloc_compat() with the response
skb and header.
xfrm_alloc_userspi() then calls alloc_compat() again, but passes the
original request skb and its header. For a compat request, the
translator therefore interprets the 228-byte compat xfrm_userspi_info
as the 232-byte native layout and reads four bytes past the declared
payload. It also publishes the translated child through the request's
frag_list.
A multicast clone of the request shares skb_shared_info and can observe
that child. xfrm_user_rcv_msg() frees it after the request handler
returns, racing a compat receiver which may still be copying from it and
resulting in a use-after-free.
Remove the redundant conversion. The response keeps its correct compat
translation from dump_one_state(), and no child is attached to the
inbound request. |
| In the Linux kernel, the following vulnerability has been resolved:
net: wwan: t7xx: validate the netif index in t7xx_ccmni_recv_skb()
The netif index carried in the DPMAIF PIT header is five bits wide,
but ccmni_inst[] only has room for NIC_DEV_MAX (21) entries.
t7xx_ccmni_recv_skb() indexes the array without a bounds check, so
indexes 21 to 31 read past it. The out-of-bounds value lands in the
callback table that follows the array, which is never NULL, so the
existing !ccmni check does not catch it and the driver dereferences
whatever sits there as a struct t7xx_ccmni.
Drop the skb when the index is out of range.
Verified in a QEMU guest with a fault injector setting the netif
index to 25: the unpatched driver reads a value past ccmni_inst[],
which lands in the callback table, and dereferences it far enough to
queue the skb. With this check the packet is dropped. Well-formed
traffic on index 0 is unaffected.
Changes in v2: none. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scpi: reject DVFS OPP count above MAX_DVFS_OPPS
scpi_dvfs_get_info() already rejected a zero opp_count, but still trusted
any larger value from the SCP firmware. The shared-memory reply only holds
MAX_DVFS_OPPS entries in buf.opps[]; a bigger count over-reads that array
and then sizes the allocated OPP table incorrectly (garbage OPPs / OOB).
The missing upper bound dates back to the original SCPI DVFS support.
Reject zero and out-of-range counts in one check and return -EINVAL. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/dax: check zero or empty entry before converting xarray entry
Calling dax_to_folio() with empty entry causes kernel panic below when
booting a VM with DAX enabled storage.
This patch checks empty entry before calling dax_to_folio() on
dax_associate_entry(), dax_disassociate_entry(), and dax_busy_page().
Commit 98c183a4fccf ("fs/dax: don't disassociate zero page entries") added
guards in the associate and disassociate paths, but the guards still come
after dax_to_folio(), and dax_busy_page() still has the same problem.
[ 0.737679] EXT4-fs (pmem0p1): mounted filesystem 79676804-7c8b-491a-b2a6-9bae3c72af70 ro with ordered data mode. Quota mode: disabled.
[ 0.737891] VFS: Mounted root (ext4 filesystem) readonly on device 259:1.
[ 0.739119] devtmpfs: mounted
[ 0.739476] Freeing unused kernel memory: 1920K
[ 0.740156] Run /sbin/init as init process
[ 0.740229] with arguments:
[ 0.740286] /sbin/init
[ 0.740321] with environment:
[ 0.740369] HOME=/
[ 0.740400] TERM=linux
[ 0.743162] Unable to handle kernel paging request at virtual address fffffdffbf000008
[ 0.743285] Mem abort info:
[ 0.743316] ESR = 0x0000000096000006
[ 0.743371] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.743444] SET = 0, FnV = 0
[ 0.743489] EA = 0, S1PTW = 0
[ 0.743545] FSC = 0x06: level 2 translation fault
[ 0.743610] Data abort info:
[ 0.743656] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 0.743720] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 0.743785] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.743848] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000b9d17000
[ 0.743931] [fffffdffbf000008] pgd=10000000bfa3d403, p4d=10000000bfa3d403, pud=1000000040bfe403, pmd=0000000000000000
[ 0.744070] Internal error: Oops: 0000000096000006 [#1] SMP
[ 0.748888] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.18.4 #1 NONE
[ 0.749421] pstate: 004000c5 (nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.749969] pc : dax_disassociate_entry.constprop.0+0x20/0x50
[ 0.750444] lr : dax_insert_entry+0xcc/0x408
[ 0.750802] sp : ffff80008000b9e0
[ 0.751083] x29: ffff80008000b9e0 x28: 0000000000000000 x27: 0000000000000000
[ 0.751682] x26: 0000000001963d01 x25: ffff0000004f7d90 x24: 0000000000000000
[ 0.752264] x23: 0000000000000000 x22: ffff80008000bcc8 x21: 0000000000000011
[ 0.752836] x20: ffff80008000ba90 x19: 0000000001963d01 x18: 0000000000000000
[ 0.753407] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 0.753970] x14: ffffbf3154b9ae70 x13: 0000000000000000 x12: ffffbf3154b9ae70
[ 0.754548] x11: ffffffffffffffff x10: 0000000000000000 x9 : 0000000000000000
[ 0.755122] x8 : 000000000000000d x7 : 000000000000001f x6 : 0000000000000000
[ 0.755707] x5 : 0000000000000000 x4 : 0000000000000000 x3 : fffffdffc0000000
[ 0.756287] x2 : 0000000000000008 x1 : 0000000040000000 x0 : fffffdffbf000000
[ 0.756871] Call trace:
[ 0.757107] dax_disassociate_entry.constprop.0+0x20/0x50 (P)
[ 0.757592] dax_iomap_pte_fault+0x4fc/0x808
[ 0.757951] dax_iomap_fault+0x28/0x30
[ 0.758258] ext4_dax_huge_fault+0x80/0x2dc
[ 0.758594] ext4_dax_fault+0x10/0x3c
[ 0.758892] __do_fault+0x38/0x12c
[ 0.759175] __handle_mm_fault+0x530/0xcf0
[ 0.759518] handle_mm_fault+0xe4/0x230
[ 0.759833] do_page_fault+0x17c/0x4dc
[ 0.760144] do_translation_fault+0x30/0x38
[ 0.760483] do_mem_abort+0x40/0x8c
[ 0.760771] el0_ia+0x4c/0x170
[ 0.761032] el0t_64_sync_handler+0xd8/0xdc
[ 0.761371] el0t_64_sync+0x168/0x16c
[ 0.761677] Code: f9453021 f2dfbfe3 cb813080 8b001860 (f9400401)
[ 0.762168] ---[ end trace 0000000000000000 ]---
[ 0.762550] note: init[1] exited with irqs disabled
[ 0.762631] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b |
