In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix busy dentry used after unmounting
Since commit 340cea84f691c ("cifs: open files should not hold ref on superblock"), cifs file only holds the dentry refcnt, the cifs file close work(cfile->deferred) could be executed after unmounting, which will trigger a warning in genericshutdownsuper: BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of cifs cifs]
The detailed processs is: process A process B kworker fd = open(PATH) vfsopen file->fpath = path // dentry->dlockref.count = 1 cifsopen cifsnewfileinfo cfile->dentry = dget(dentry) // dentry->dlockref.count = 2 close(fd) fput cifsclose queuedelayedwork(deferredclosewq, cfile->deferred) dput(dentry) // dentry->dlockref.count = 1 smb2deferredworkclose cifsFileInfoput listdel(&cifsfile->flist) umount cleanupmnt deactivatesuper cifskillsb cifsclosealldeferredfilessb cifsclosealldeferredfiles // cannot find cfile, skip cifsFileInfoput killanonsuper genericshutdownsuper shrinkdcacheforumount umountcheck WARN ! // dentry->dlockref.count = 1 cifsFileInfoputfinal dput(cifsfile->dentry) // dentry->dlockref.count = 0
Fix it by flushing 'deferredclosewq' before calling killanonsuper.
Fetch a reproducer in https://bugzilla.kernel.org/showbug.cgi?id=221548.
In the Linux kernel, the following vulnerability has been resolved:
net-shapers: don't free reply skb after genlmsgreply()
genlmsgreply() hands the reply skb to netlink, and netlinkunicast() consumes it on all return paths, whether the skb is queued successfully or freed on an error path.
netshapernlgetdoit() and netshapernlcapgetdoit() currently jump to freemsg after genlmsgreply() fails and call nlmsgfree(msg), which can hit the same skb twice.
Return the genlmsgreply() error directly and keep freemsg only for pre-reply failures.
In the Linux kernel, the following vulnerability has been resolved:
iio: chemical: sps30i2c: fix buffer size in sps30i2creadmeas()
sizeof(num) evaluates to sizeof(sizet) (8 bytes on 64-bit) instead of the intended be32 element size (4 bytes). Use sizeof(meas) to correctly match the buffer element type.
In the Linux kernel, the following vulnerability has been resolved:
xprtrdma: Decrement rereceiving on the early exit paths
In the event that rpcrdmapostrecvs() fails to create a work request (due to memory allocation failure, say) or otherwise exits early, we should decrement ep->rereceiving before returning. Otherwise we will hang in rpcrdmaxprtdrain() as rereceiving will never reach zero and the completion will never be triggered.
On a system with high memory pressure, this can appear as the following hung task:
INFO: task kworker/u385:17:8393 blocked for more than 122 seconds. Tainted: G S E 6.19.0 #3 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u385:17 state:D stack:0 pid:8393 tgid:8393 ppid:2 taskflags:0x4248060 flags:0x00080000 Workqueue: xprtiod xprtautoclose [sunrpc] Call Trace: <TASK> schedule+0x48b/0x18b0 ? ibpostsendmad+0x247/0xae0 [ibcore] schedule+0x27/0xf0 scheduletimeout+0x104/0x110 waitforcommon+0x98/0x180 ? pfxscheduletimeout+0x10/0x10 waitforcompletion+0x24/0x40 rpcrdmaxprtdisconnect+0x444/0x460 [rpcrdma] xprtrdmaclose+0x12/0x40 [rpcrdma] xprtautoclose+0x5f/0x120 [sunrpc] processonework+0x191/0x3e0 workerthread+0x2e3/0x420 ? pfxworkerthread+0x10/0x10 kthread+0x10d/0x230 ? pfxkthread+0x10/0x10 retfromfork+0x273/0x2b0 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery
In case of a TX error CQE, a recovery flow is triggered, mlx5eresettxqsqccpc() resets dmafifocc to 0 but not dmafifopc, desyncing the DMA FIFO producer and consumer.
After recovery, the producer pushes new DMA entries at the old dmafifopc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery.
The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dmafifocc is already equal to dmafifopc. There is no need to reset either counter, similar to how skbfifo pc/cc are untouched.
Remove the 'dmafifocc = 0' reset.
This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommudmaunmappage+0x79/0x90 Modules linked in: mlx5vdpa vringh vdpa bonding mlx5ib mlx5vfiopci ipip mlx5fwctl tunnel4 mlx5core ibipoib geneve ip6gre ipgre gre nftables ip6tunnel rdmaucm ibuverbs ibumad vfiopci vfiopcicore actmirred actskbedit actvlan vhostnet vhost tap ip6tablemangle ip6tablenat ip6tablefilter ip6tables iptablemangle clsmatchall nfnetlinkcttimeout actgact clsflower schingress vhostiotlb iptableraw tunnel6 vfioiommutype1 vfio openvswitch nsh rpcsecgsskrb5 authrpcgss oidregistry xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink iptablenat nfnat xtaddrtype brnetfilter overlay zram zsmalloc rpcrdma ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm ibcore fuse [last unloaded: nftables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5forupstreammindebug202412302133 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommudmaunmappage+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: <IRQ> ? warn+0x7d/0x110 ? iommudmaunmappage+0x79/0x90 ? reportbug+0x16d/0x180 ? handlebug+0x4f/0x90 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? iommudmaunmappage+0x79/0x90 ? iommudmaunmappage+0x2e/0x90 dmaunmappageattrs+0x10d/0x1b0 mlx5etxwidmaunmap+0xbe/0x120 [mlx5core] mlx5epolltxcq+0x16d/0x690 [mlx5core] mlx5enapipoll+0x8b/0xac0 [mlx5core] napipoll+0x24/0x190 netrxaction+0x32a/0x3b0 ? mlx5eqcompint+0x7e/0x270 [mlx5core] ? notifiercallchain+0x35/0xa0 handlesoftirqs+0xc9/0x270 irqexitrcu+0x71/0xd0 commoninterrupt+0x7f/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x22/0x40
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: RX, Fix XDP multi-buf frag counting for legacy RQ
XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpfxdppulldata() or bpfxdpadjusttail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.
Such issue can be observed with the testxdpnativeadjsttailshrnkdata selftest when using a payload of 3600 and shrinking by 256 bytes (an upcoming selftest patch): the last fragment gets released by the XDP code but doesn't get tracked by the driver. This results in a negative pprefcount during page release and the following splat:
WARNING: include/net/pagepool/helpers.h:297 at mlx5epagereleasefragmented.isra.0+0x4a/0x50 [mlx5core], CPU#12: ip/3137 Modules linked in: [...] CPU: 12 UID: 0 PID: 3137 Comm: ip Not tainted 6.19.0-rc3+ #12 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5epagereleasefragmented.isra.0+0x4a/0x50 [mlx5core] [...] Call Trace: <TASK> mlx5edeallocrxwqe+0xcb/0x1a0 [mlx5core] mlx5efreerxdescs+0x7f/0x110 [mlx5core] mlx5ecloserq+0x50/0x60 [mlx5core] mlx5eclosequeues+0x36/0x2c0 [mlx5core] mlx5eclosechannel+0x1c/0x50 [mlx5core] mlx5eclosechannels+0x45/0x80 [mlx5core] mlx5esafeswitchparams+0x1a5/0x230 [mlx5core] mlx5echangemtu+0xf3/0x2f0 [mlx5core] netifsetmtuext+0xf1/0x230 dosetlink.isra.0+0x219/0x1180 rtnlnewlink+0x79f/0xb60 rtnetlinkrcvmsg+0x213/0x3a0 netlinkrcvskb+0x48/0xf0 netlinkunicast+0x24a/0x350 netlinksendmsg+0x1ee/0x410 socksendmsg+0x38/0x60 syssendmsg+0x232/0x280 syssendmsg+0x78/0xb0 syssendmsg+0x5f/0xb0 [...] dosyscall64+0x57/0xc50
This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDPTX , XDPREDIRECT and XDPPASS). This is basically reverting to the original counting before the commit in the fixes tag.
As fragpage is still pointing to the original tail, the nrfrags parameter to xdpupdateskbfragsinfo() needs to be calculated in a different way to reflect the new nrfrags.
In the Linux kernel, the following vulnerability has been resolved:
net: spacemit: Fix error handling in emactxmemmap()
The DMA mappings were leaked on mapping error. Free them with the existing emacfreetxbuf() function.
In the Linux kernel, the following vulnerability has been resolved:
spi: amlogic: spifc-a4: Fix DMA mapping error handling
Fix three bugs in amlsfcdmabuffersetup() error paths: 1. Unnecessary goto: When the first DMA mapping (sfc->daddr) fails, nothing needs cleanup. Use direct return instead of goto. 2. Double-unmap bug: When info DMA mapping failed, the code would unmap sfc->daddr inline, then fall through to outmapdata which would unmap it again, causing a double-unmap. 3. Wrong unmap size: The outmapinfo label used datalen instead of infolen when unmapping sfc->iaddr, which could lead to incorrect DMA sync behavior.
In the Linux kernel, the following vulnerability has been resolved:
spi: rockchip-sfc: Fix double-free in remove() callback
The driver uses devmspiregistercontroller() for registration, which automatically unregisters the controller via devm cleanup when the device is removed. The manual call to spiunregistercontroller() in the remove() callback can lead to a double-free.
And to make sure controller is unregistered before DMA buffer is unmapped, switch to use spiregistercontroller() in probe().
In the Linux kernel, the following vulnerability has been resolved:
ASoC: soc-core: flush delayed work before removing DAIs and widgets
When a sound card is unbound while a PCM stream is open, a use-after-free can occur in sndsocdapmstreamevent(), called from the closedelayedwork workqueue handler.
During unbind, sndsocunbindcard() flushes delayed work and then calls soccleanupcardresources(). Inside cleanup, sndcarddisconnectsync() releases all PCM file descriptors, and the resulting PCM close path can call sndsocdapmstreamstop() which schedules new delayed work with a pmdowntime timer delay. Since this happens after the flush in sndsocunbindcard(), the new work is not caught. socremovelinkcomponents() then frees DAPM widgets before this work fires, leading to the use-after-free.
The existing flush in socfreepcmruntime() also cannot help as it runs after socremovelinkcomponents() has already freed the widgets.
Add a flush in soccleanupcardresources() after sndcarddisconnectsync() (after which no new PCM closes can schedule further delayed work) and before socremovelinkdais() and socremovelinkcomponents() (which tear down the structures the delayed work accesses).
In the Linux kernel, the following vulnerability has been resolved:
serial: caif: hold tty->link reference in ldiscopen and serrelease
A reproducer triggers a KASAN slab-use-after-free in ptywriteroom() when caifserial's TX path calls ttywriteroom(). The faulting access is on tty->link->port.
Hold an extra kref on tty->link for the lifetime of the caifserial line discipline: get it in ldiscopen() and drop it in serrelease(), and also drop it on the ldiscopen() error path.
With this change applied, the reproducer no longer triggers the UAF in my testing.
In the Linux kernel, the following vulnerability has been resolved:
bonding: fix type confusion in bondsetupbyslave()
kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskbexpandhead+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace: <TASK> ipgreheader+0xdd/0x540 net/ipv4/ipgre.c:900 devhardheader include/linux/netdevice.h:3439 [inline] packetsnd net/packet/afpacket.c:3028 [inline] packetsendmsg+0x3ae5/0x53c0 net/packet/afpacket.c:3108 socksendmsgnosec net/socket.c:727 [inline] socksendmsg net/socket.c:742 [inline] syssendmsg+0xa54/0xc30 net/socket.c:2592 syssendmsg+0x190/0x1e0 net/socket.c:2646 syssendmsg+0x170/0x220 net/socket.c:2678 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0x106/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9
When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bondsetupbyslave() directly copies the slave's headerops to the bond device:
bonddev->headerops = slavedev->headerops;
This causes a type confusion when devhardheader() is later called on the bond device. Functions like ipgreheader(), ip6greheader(),all use netdevpriv(dev) to access their device-specific private data. When called with the bond device, netdevpriv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct iptunnel), leading to garbage values being read and kernel crashes.
Fix this by introducing bondheaderops with wrapper functions that delegate to the active slave's headerops using the slave's own device. This ensures netdevpriv() in the slave's header functions always receives the correct device.
The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting headerops from the slave without considering that these callbacks expect a specific netdevpriv() layout.
The type confusion can be observed by adding a printk in ipgreheader() and running the following commands:
ip link add dummy0 type dummy ip addr add 10.0.0.1/24 dev dummy0 ip link set dummy0 up ip link add gre1 type gre local 10.0.0.1 ip link add bond1 type bond mode active-backup ip link set gre1 master bond1 ip link set gre1 up ip link set bond1 up ip addr add fe80::1/64 dev bond1
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftsetpipapo: fix stack out-of-bounds read in pipapodrop()
pipapodrop() passes rulemap[i + 1].n to pipapounmap() as the tooffset argument on every iteration, including the last one where i == m->fieldcount - 1. This reads one element past the end of the stack-allocated rulemap array (declared as rulemap[NFTPIPAPOMAXFIELDS] with NFTPIPAPOMAXFIELDS == 16).
Although pipapounmap() returns early when islast is true without using the tooffset value, the argument is evaluated at the call site before the function body executes, making this a genuine out-of-bounds stack read confirmed by KASAN:
BUG: KASAN: stack-out-of-bounds in pipapodrop+0x50c/0x57c [nftables] Read of size 4 at addr ffff8000810e71a4
This frame has 1 object: [32, 160) 'rulemap'
The buggy address is at offset 164 -- exactly 4 bytes past the end of the rulemap array.
Pass 0 instead of rulemap[i + 1].n on the last iteration to avoid the out-of-bounds read.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: Fix for duplicate device in netdev hooks
When handling NETDEVREGISTER notification, duplicate device registration must be avoided since the device may have been added by nftnetdevhookalloc() already when creating the hook.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtables: guard option walkers against 1-byte tail reads
When the last byte of options is a non-single-byte option kind, walkers that advance with i += op[i + 1] ? : 1 can read op[i + 1] past the end of the option area.
Add an explicit i == optlen - 1 check before dereferencing op[i + 1] in xttcpudp and xtdccp option walkers.
In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: Fix slab-out-of-bounds in nvmedbbufset
dev->onlinequeues is a count incremented in nvmeinitqueue. Thus, valid indices are 0 through dev->onlinequeues − 1.
This patch fixes the loop condition to ensure the index stays within the valid range. Index 0 is excluded because it is the admin queue.
KASAN splat:
================================================================== BUG: KASAN: slab-out-of-bounds in nvmedbbuffree drivers/nvme/host/pci.c:377 [inline] BUG: KASAN: slab-out-of-bounds in nvmedbbufset+0x39c/0x400 drivers/nvme/host/pci.c:404 Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74
CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: nvme-reset-wq nvmeresetwork Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0xea/0x150 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xce/0x5d0 mm/kasan/report.c:482 kasanreport+0xdc/0x110 mm/kasan/report.c:595 asanreportload2noabort+0x18/0x20 mm/kasan/reportgeneric.c:379 nvmedbbuffree drivers/nvme/host/pci.c:377 [inline] nvmedbbufset+0x39c/0x400 drivers/nvme/host/pci.c:404 nvmeresetwork+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246 </TASK>
Allocated by task 34 on cpu 1 at 4.241550s: kasansavestack+0x2c/0x60 mm/kasan/common.c:57 kasansavetrack+0x1c/0x70 mm/kasan/common.c:78 kasansaveallocinfo+0x3c/0x50 mm/kasan/generic.c:570 poisonkmallocredzone mm/kasan/common.c:398 [inline] kasankmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasankmalloc include/linux/kasan.h:263 [inline] dokmallocnode mm/slub.c:5657 [inline] kmallocnodenoprof+0x2bf/0x8d0 mm/slub.c:5663 kmallocarraynodenoprof include/linux/slab.h:1075 [inline] nvmepciallocdev drivers/nvme/host/pci.c:3479 [inline] nvmeprobe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 localpciprobe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pcicallprobe drivers/pci/pci-driver.c:392 [inline] pcideviceprobe drivers/pci/pci-driver.c:417 [inline] pcideviceprobe+0x743/0x920 drivers/pci/pci-driver.c:451 calldriverprobe drivers/base/dd.c:583 [inline] reallyprobe+0x29b/0xb70 drivers/base/dd.c:661 driverprobedevice+0x3b0/0x4a0 drivers/base/dd.c:803 driverprobedevice+0x56/0x1f0 drivers/base/dd.c:833 driverattachasynchelper+0x155/0x340 drivers/base/dd.c:1159 asyncrunentryfn+0xa6/0x4b0 kernel/async.c:129 processonework+0x956/0x1aa0 kernel/workqueue.c:3257 processscheduledworks kernel/workqueue.c:3340 [inline] workerthread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 retfromfork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246
The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480)
The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928 head: order:3 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff) pagetype: f5(slab) raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000 head: 000fffffc0000040 ffff888001042000 00000 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfnetlinkcthelper: fix OOB read in nfnlcthelperdumptable()
nfnlcthelperdumptable() has a 'goto restart' that jumps to a label inside the for loop body. When the "last" helper saved in cb->args[1] is deleted between dump rounds, every entry fails the (cur != last) check, so cb->args[1] is never cleared. The for loop finishes with cb->args[0] == nfcthelperhsize, and the 'goto restart' jumps back into the loop body bypassing the bounds check, causing an 8-byte out-of-bounds read on nfcthelperhash[nfcthelperhsize].
The 'goto restart' block was meant to re-traverse the current bucket when "last" is no longer found, but it was placed after the for loop instead of inside it. Move the block into the for loop body so that the restart only occurs while cb->args[0] is still within bounds.
BUG: KASAN: slab-out-of-bounds in nfnlcthelperdumptable+0x9f/0x1b0 Read of size 8 at addr ffff888104ca3000 by task poccthelper/131 Call Trace: nfnlcthelperdumptable+0x9f/0x1b0 netlinkdump+0x333/0x880 netlinkrecvmsg+0x3e2/0x4b0 sockrecvmsg+0xde/0xf0 sysrecvfrom+0x150/0x200 x64sysrecvfrom+0x76/0x90 dosyscall64+0xc3/0x6e0
Allocated by task 1: kvmallocnodenoprof+0x21b/0x700 nfctallochashtable+0x65/0xd0 nfconntrackhelperinit+0x21/0x60 nfconntrackinitstart+0x18d/0x300 nfconntrackstandaloneinit+0x12/0xc0
In the Linux kernel, the following vulnerability has been resolved:
iavf: fix PTP use-after-free during reset
Commit 7c01dbfc8a1c5f ("iavf: periodically cache PHC time") introduced a worker to cache PHC time, but failed to stop it during reset or disable.
This creates a race condition where iavfresettask() or iavfdisablevf() free adapter resources (AQ) while the worker is still running. If the worker triggers iavfqueueptpcmd() during teardown, it accesses freed memory/locks, leading to a crash.
Fix this by calling iavfptprelease() before tearing down the adapter. This ensures ptpclockunregister() synchronously cancels the worker and cleans up the chardev before the backing resources are destroyed.
In the Linux kernel, the following vulnerability has been resolved:
iouring: fix physical SQE bounds check for SQEMIXED 128-byte ops
When IORINGSETUPSQEMIXED is used without IORINGSETUPNOSQARRAY, the boundary check for 128-byte SQE operations in ioinitreq() validated the logical SQ head position rather than the physical SQE index.
The existing check:
!(ctx->cachedsqhead & (ctx->sqentries - 1))
ensures the logical position isn't at the end of the ring, which is correct for NOSQARRAY rings where physical == logical. However, when sqarray is present, an unprivileged user can remap any logical position to an arbitrary physical index via sqarray. Setting sqarray[N] = sqentries - 1 places a 128-byte operation at the last physical SQE slot, causing the 128-byte memcpy in iouringcmdsqecopy() to read 64 bytes past the end of the SQE array.
Replace the cachedsqhead alignment check with a direct validation of the physical SQE index, which correctly handles both sqarray and NOSQARRAY cases.
In the Linux kernel, the following vulnerability has been resolved:
net/mana: Null servicewq on setup error to prevent double destroy
In managdsetup() error path, set gc->servicewq to NULL after destroyworkqueue() to match the cleanup in managdcleanup(). This prevents a use-after-free if the workqueue pointer is checked after a failed setup.
In the Linux kernel, the following vulnerability has been resolved:
net: bonding: Fix ndtbl NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, the ndtbl is never initialized because inet6init() exits before ndiscinit() is called which initializes it. If bonding ARP/NS validation is enabled, an IPv6 NS/NA packet received on a slave can reach bondvalidatena(), which calls bondhasthisip6(). That path calls ipv6chkaddr() and can crash in ipv6chkaddrandflags().
BUG: kernel NULL pointer dereference, address: 00000000000005d8 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:ipv6chkaddrandflags+0x69/0x170 Call Trace: <IRQ> ipv6chkaddr+0x1f/0x30 bondvalidatena+0x12e/0x1d0 [bonding] ? pfxbondhandleframe+0x10/0x10 [bonding] bondrcvvalidate+0x1a0/0x450 [bonding] bondhandleframe+0x5e/0x290 [bonding] ? srsoaliasreturnthunk+0x5/0xfbef5 netifreceiveskbcore.constprop.0+0x3e8/0xe50 ? srsoaliasreturnthunk+0x5/0xfbef5 ? updatecfsrqloadavg+0x1a/0x240 ? srsoaliasreturnthunk+0x5/0xfbef5 ? enqueueentity+0x5e/0x240 netifreceiveskbonecore+0x39/0xa0 processbacklog+0x9c/0x150 napipoll+0x30/0x200 ? srsoaliasreturnthunk+0x5/0xfbef5 netrxaction+0x338/0x3b0 handlesoftirqs+0xc9/0x2a0 dosoftirq+0x42/0x60 </IRQ> <TASK> localbhenableip+0x62/0x70 devqueuexmit+0x2d3/0x1000 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? packetparseheaders+0x10a/0x1a0 packetsendmsg+0x10da/0x1700 ? kickpool+0x5f/0x140 ? srsoaliasreturnthunk+0x5/0xfbef5 ? queuework+0x12d/0x4f0 syssendto+0x1f3/0x220 x64syssendto+0x24/0x30 dosyscall64+0x101/0xf80 ? excpagefault+0x6e/0x170 ? srsoaliasreturnthunk+0x5/0xfbef5 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
Fix this by checking ipv6modenabled() before dispatching IPv6 packets to bondnarcv(). If IPv6 is disabled, return early from bondrcvvalidate() and avoid the path to ipv6chkaddr().
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: fix use-after-free on linked stream runtime in sndpcmdrain()
In the drain loop, the local variable 'runtime' is reassigned to a linked stream's runtime (runtime = s->runtime at line 2157). After releasing the stream lock at line 2169, the code accesses runtime->noperiodwakeup, runtime->rate, and runtime->buffersize (lines 2170-2178) — all referencing the linked stream's runtime without any lock or refcount protecting its lifetime.
A concurrent close() on the linked stream's fd triggers sndpcmreleasesubstream() → sndpcmdrop() → pcmreleaseprivate() → sndpcmunlink() → sndpcmdetachsubstream() → kfree(runtime). No synchronization prevents kfree(runtime) from completing while the drain path dereferences the stale pointer.
Fix by caching the needed runtime fields (noperiodwakeup, rate, buffersize) into local variables while still holding the stream lock, and using the cached values after the lock is released.
In the Linux kernel, the following vulnerability has been resolved:
rustbinder: check ownership before using vma
When installing missing pages (or zapping them), Rust Binder will look up the vma in the mm by address, and then call vminsertpage (or zappagerangesingle). However, if the vma is closed and replaced with a different vma at the same address, this can lead to Rust Binder installing pages into the wrong vma.
By installing the page into a writable vma, it becomes possible to write to your own binder pages, which are normally read-only. Although you're not supposed to be able to write to those pages, the intent behind the design of Rust Binder is that even if you get that ability, it should not lead to anything bad. Unfortunately, due to another bug, that is not the case.
To fix this, store a pointer in vmprivatedata and check that the vma returned by vmalookup() has the right vmops and vmprivatedata before trying to use the vma. This should ensure that Rust Binder will refuse to interact with any other VMA. The plan is to introduce more vma abstractions to avoid this unsafe access to vmops and vmprivatedata, but for now let's start with the simplest possible fix.
C Binder performs the same check in a slightly different way: it provides a vmops->close that sets a boolean to true, then checks that boolean after calling vmalookup(), but this is more fragile than the solution in this patch. (We probably still want to do both, but the vmops->close callback will be added later as part of the follow-up vma API changes.)
It's still possible to remap the vma so that pages appear in the right vma, but at the wrong offset, but this is a separate issue and will be fixed when Rust Binder gets a vmops->close callback.
In the Linux kernel, the following vulnerability has been resolved:
rustbinder: avoid reading the written value in offsets array
When sending a transaction, its offsets array is first copied into the target proc's vma, and then the values are read back from there. This is normally fine because the vma is a read-only mapping, so the target process cannot change the value under us.
However, if the target process somehow gains the ability to write to its own vma, it could change the offset before it's read back, causing the kernel to misinterpret what the sender meant. If the sender happens to send a payload with a specific shape, this could in the worst case lead to the receiver being able to privilege escalate into the sender.
The intent is that gaining the ability to change the read-only vma of your own process should not be exploitable, so remove this TOCTOU read even though it's unexploitable without another Binder bug.
In the Linux kernel, the following vulnerability has been resolved:
usb: class: cdc-wdm: fix reordering issue in read code path
Quoting the bug report:
Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdmread() can see the new length and call copytouser() on uninitialized memory. This also violates LKMM data race rules [1].
Fix it by using WRITEONCE and memory barriers.
In the Linux kernel, the following vulnerability has been resolved:
usb: renesasusbhs: fix use-after-free in ISR during device removal
In usbhsremove(), the driver frees resources (including the pipe array) while the interrupt handler (usbhsinterrupt) is still registered. If an interrupt fires after usbhspiperemove() but before the driver is fully unbound, the ISR may access freed memory, causing a use-after-free.
Fix this by calling devmfreeirq() before freeing resources. This ensures the interrupt handler is both disabled and synchronized (waits for any running ISR to complete) before usbhspiperemove() is called.
In the Linux kernel, the following vulnerability has been resolved:
ceph: add a bunch of missing cephpathinfo initializers
cephmdscbuildpath() must be called with a zero-initialized cephpathinfo parameter, or else the following cephmdscfreepathinfo() may crash.
Example crash (on Linux 6.18.12):
virttocache: Object is not a Slab page! WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6732 kmemcachefree+0x316/0x400 [...] Call Trace: [...] cephopen+0x13d/0x3e0 dodentryopen+0x134/0x480 vfsopen+0x2a/0xe0 pathopenat+0x9a3/0x1160 [...] cachefromobj: Wrong slab cache. namescache but object is from cephinodeinfo WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6746 kmemcachefree+0x2dd/0x400 [...] kernel BUG at mm/slub.c:634! Oops: invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:slabfree+0x1a4/0x350
Some of the cephmdscbuildpath() callers had initializers, but others had not, even though they were all added by commit 15f519e9f883 ("ceph: fix race condition validating rparent before applying state"). The ones without initializer are suspectible to random crashes. (I can imagine it could even be possible to exploit this bug to elevate privileges.)
Unfortunately, these Ceph functions are undocumented and its semantics can only be derived from the code. I see that cephmdscbuildpath() initializes the structure only on success, but not on error.
Calling cephmdscfreepathinfo() after a failed cephmdscbuildpath() call does not even make sense, but that's what all callers do, and for it to be safe, the structure must be zero-initialized. The least intrusive approach to fix this is therefore to add initializers everywhere.
In the Linux kernel, the following vulnerability has been resolved:
libceph: Use u32 for non-negative values in cephmonmapdecode()
This patch fixes unnecessary implicit conversions that change signedness of bloblen and nummon in cephmonmapdecode(). Currently bloblen and nummon are (signed) int variables. They are used to hold values that are always non-negative and get assigned in cephdecode32safe(), which is meant to assign u32 values. Both variables are subsequently used as unsigned values, and the value of nummon is further assigned to monmap->nummon, which is of type u32. Therefore, both variables should be of type u32. This is especially relevant for nummon. If the value read from the incoming message is very large, it is interpreted as a negative value, and the check for nummon > CEPHMAXMON does not catch it. This leads to the attempt to allocate a very large chunk of memory for monmap, which will most likely fail. In this case, an unnecessary attempt to allocate memory is performed, and -ENOMEM is returned instead of -EINVAL.
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/core: clear walkcontrol on inactive context in damoswalk()
damoswalk() sets ctx->walkcontrol to the caller-provided control structure before checking whether the context is running. If the context is inactive (damonisrunning() returns false), the function returns -EINVAL without clearing ctx->walkcontrol. This leaves a dangling pointer to a stack-allocated structure that will be freed when the caller returns.
This is structurally identical to the bug fixed in commit f9132fbc2e83 ("mm/damon/core: remove callcontrol in inactive contexts") for damoncall(), which had the same pattern of linking a control object and returning an error without unlinking it.
The dangling walkcontrol pointer can cause: 1. Use-after-free if the context is later started and kdamond dereferences ctx->walkcontrol (e.g., in damoswalkcancel() which writes to control->canceled and calls complete()) 2. Permanent -EBUSY from subsequent damoswalk() calls, since the stale pointer is non-NULL
Nonetheless, the real user impact is quite restrictive. The use-after-free is impossible because there is no damoswalk() callers who starts the context later. The permanent -EBUSY can actually confuse users, as DAMON is not running. But the symptom is kept only while the context is turned off. Turning it on again will make DAMON internally uses a newly generated damonctx object that doesn't have the invalid damoswalkcontrol pointer, so everything will work fine again.
Fix this by clearing ctx->walkcontrol under walkcontrollock before returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix potential out-of-bounds read in rtwrestructwmmie
The current code checks 'i + 5 < inlen' at the end of the if statement. However, it accesses 'inie[i + 5]' before that check, which can lead to an out-of-bounds read. Move the length check to the beginning of the conditional to ensure the index is within bounds before accessing the array.