In the Linux kernel, the following vulnerability has been resolved:
net: gro: don't merge zcopy skbs
skbgroreceive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFLMANAGEDFRAGREFS flag.
When SKBFLMANAGEDFRAGREFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.
When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.
flowdissector: do not dissect PPPoE PFC frames
In the Linux kernel, the following vulnerability has been resolved:
spi: fix use-after-free on controller registration failure
Make sure to deregister from driver core also in the unlikely event that per-cpu statistics allocation fails during controller registration to avoid use-after-free (of driver resources) and unclocked register accesses.
bpf: Fix a UAF issue in bpftrampolinelinkcgroupshim
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtk-star-emac: fix spinlock recursion issues on rx/tx poll
Use spinlockirqsave and spinunlockirqrestore instead of spinlock and spinunlock in mtkstaremac driver to avoid spinlock recursion occurrence that can happen when enabling the DMA interrupts again in rx/tx poll.
BUG: spinlock recursion on CPU#0, swapper/0/0 lock: 0xffff00000db9cf20, .magic: dead4ead, .owner: swapper/0/0, .ownercpu: 0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.15.0-rc2-next-20250417-00001-gf6a27738686c-dirty #28 PREEMPT Hardware name: MediaTek MT8365 Open Platform EVK (DT) Call trace: showstack+0x18/0x24 (C) dumpstacklvl+0x60/0x80 dumpstack+0x18/0x24 spindump+0x78/0x88 dorawspinlock+0x11c/0x120 rawspinlock+0x20/0x2c mtkstarhandleirq+0xc0/0x22c [mtkstaremac] handleirqeventpercpu+0x48/0x140 handleirqevent+0x4c/0xb0 handlefasteoiirq+0xa0/0x1bc handleirqdesc+0x34/0x58 generichandledomainirq+0x1c/0x28 gichandleirq+0x4c/0x120 dointerrupthandler+0x50/0x84 el1interrupt+0x34/0x68 el1h64irqhandler+0x18/0x24 el1h64irq+0x6c/0x70 regmapmmioread32le+0xc/0x20 (P) regmapbusregread+0x6c/0xac regmapread+0x60/0xdc regmapread+0x4c/0x80 mtkstarrxpoll+0x2f4/0x39c [mtkstaremac] napipoll+0x38/0x188 netrxaction+0x164/0x2c0 handlesoftirqs+0x100/0x244 dosoftirq+0x14/0x20 dosoftirq+0x10/0x20 callonirqstack+0x24/0x64 dosoftirqownstack+0x1c/0x40 irqexitrcu+0xd4/0x10c irqexitrcu+0x10/0x1c el1interrupt+0x38/0x68 el1h64irqhandler+0x18/0x24 el1h64irq+0x6c/0x70 cpuidleenterstate+0xac/0x320 (P) cpuidleenter+0x38/0x50 doidle+0x1e4/0x260 cpustartupentry+0x34/0x3c restinit+0xdc/0xe0 consoleonrootfs+0x0/0x6c primaryswitched+0x88/0x90
In the Linux kernel, the following vulnerability has been resolved:
fs: fix UAF/GPF bug in nilfsmdtdestroy
In allocinode, inodeinitalways() could return -ENOMEM if securityinodealloc() fails, which causes inode->iprivate uninitialized. Then nilfsismetadatafileinode() returns true and nilfsfreeinode() wrongly calls nilfsmdtdestroy(), which frees the uninitialized inode->iprivate and leads to crashes(e.g., UAF/GPF).
Fix this by moving securityinodealloc just prior to thiscpuinc(nrinodes)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix user-after-free
This uses l2capchanholdunlesszero() after calling l2capgetchanblah() to prevent the following trace:
Bluetooth: l2capcore.c:static void l2capchandestroy(struct kref kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in mutexwaiterisfirst kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in mutexlockcommon kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in mutexlock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389
In ip6appenddata(), when the paged-allocation branch is taken (MSGMORE / NETIFFSG / large fraglen), alloclen and pagedlen are computed as
alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen;
datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skbsharedinfo.
An unprivileged user can trigger this via a UDPv6 socket using MSGMORE together with MSGSPLICEPAGES.
The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix ip6appenddata()'s handling of MSGSPLICEPAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSGSPLICEPAGES to proceed in this case, making the corruption triggerable.
The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen.
After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSGSPLICEPAGES case, remove the MSGSPLICEPAGES exception from the negative copy check.
In the Linux kernel, the following vulnerability has been resolved:
tls: handle data disappearing from under the TLS ULP
TLS expects that it owns the receive queue of the TCP socket. This cannot be guaranteed in case the reader of the TCP socket entered before the TLS ULP was installed, or uses some non-standard read API (eg. zerocopy ones). Replace the WARNON() and a buggy early exit (which leaves anchor pointing to a freed skb) with real error handling. Wipe the parsing state and tell the reader to retry.
We already reload the anchor every time we (re)acquire the socket lock, so the only condition we need to avoid is an out of bounds read (not having enough bytes in the socket for previously parsed record len).
If some data was read from under TLS but there's enough in the queue we'll reload and decrypt what is most likely not a valid TLS record. Leading to some undefined behavior from TLS perspective (corrupting a stream? missing an alert? missing an attack?) but no kernel crash should take place.
Bluetooth: hciconn: fix potential UAF in createbigsync
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in port "disable" sysfs attribute
The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration:
Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and devicedel() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then.
But the disableshow() or disablestore() routine can't return until after it has acquired the lock.
The resulting deadlock can be avoided by calling sysfsbreakactiveprotection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hubget().
fbdev: fbcon: fix out-of-bounds read in errout of fbcondosetfont()
In the Linux kernel, the following vulnerability has been resolved:
ipv4: account for fraggap on the paged allocation path
In ipappenddata(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as
alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen;
datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skbcopyandcsumbits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount.
The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen.
After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: SDMA update use unlocked iterator
SDMA update page table may be called from unlocked context, this generate below warning. Use unlocked iterator to handle this case.
WARNING: CPU: 0 PID: 1475 at drivers/dma-buf/dma-resv.c:483 dmaresviternext Call Trace: dmaresviterfirst+0x43/0xa0 amdgpuvmsdmaupdate+0x69/0x2d0 [amdgpu] amdgpuvmptesupdate+0x29c/0x870 [amdgpu] amdgpuvmupdaterange+0x2f6/0x6c0 [amdgpu] svmrangeunmapfromgpus+0x115/0x300 [amdgpu] svmrangecpuinvalidatepagetables+0x510/0x5e0 [amdgpu] mmunotifierinvalidaterangestart+0x1d3/0x230 unmapvmas+0x140/0x150 unmapregion+0xa8/0x110
In the Linux kernel, the following vulnerability has been resolved:
drm/meson: reorder driver deinit sequence to fix use-after-free bug
Unloading the driver triggers the following KASAN warning:
[ +0.006275] ============================================================= [ +0.000029] BUG: KASAN: use-after-free in listdelentryvalid+0xe0/0x1a0 [ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695
[ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000007] dumpbacktrace+0x1ec/0x280 [ +0.000013] showstack+0x24/0x80 [ +0.000008] dumpstacklvl+0x98/0xd4 [ +0.000011] printaddressdescription.constprop.0+0x80/0x520 [ +0.000011] printreport+0x128/0x260 [ +0.000007] kasanreport+0xb8/0xfc [ +0.000008] asanreportload8noabort+0x3c/0x50 [ +0.000010] listdelentryvalid+0xe0/0x1a0 [ +0.000009] drmatomicprivateobjfini+0x30/0x200 [drm] [ +0.000172] drmbridgedetach+0x94/0x260 [drm] [ +0.000145] drmencodercleanup+0xa4/0x290 [drm] [ +0.000144] drmmodeconfigcleanup+0x118/0x740 [drm] [ +0.000143] drmmodeconfiginitrelease+0x1c/0x2c [drm] [ +0.000144] drmmanagedrelease+0x170/0x414 [drm] [ +0.000142] drmdevput.part.0+0xc0/0x124 [drm] [ +0.000143] drmdevput+0x20/0x30 [drm] [ +0.000142] mesondrvunbind+0x1d8/0x2ac [mesondrm] [ +0.000028] takedownaggregatedevice+0xb0/0x160 [ +0.000016] componentdel+0x18c/0x360 [ +0.000009] mesondwhdmiremove+0x28/0x40 [mesondwhdmi] [ +0.000015] platformremove+0x64/0xb0 [ +0.000009] deviceremove+0xb8/0x154 [ +0.000009] devicereleasedriverinternal+0x398/0x5b0 [ +0.000009] driverdetach+0xac/0x1b0 [ +0.000009] busremovedriver+0x158/0x29c [ +0.000009] driverunregister+0x70/0xb0 [ +0.000008] platformdriverunregister+0x20/0x2c [ +0.000008] mesondwhdmiplatformdriverexit+0x1c/0x30 [mesondwhdmi] [ +0.000012] dosysdeletemodule+0x288/0x400 [ +0.000011] arm64sysdeletemodule+0x5c/0x80 [ +0.000009] invokesyscall+0x74/0x260 [ +0.000009] el0svccommon.constprop.0+0xcc/0x260 [ +0.000009] doel0svc+0x50/0x70 [ +0.000007] el0svc+0x68/0x1a0 [ +0.000012] el0t64synchandler+0x11c/0x150 [ +0.000008] el0t64sync+0x18c/0x190
[ +0.000018] Allocated by task 0: [ +0.000007] (stack is not available)
[ +0.000011] Freed by task 2695: [ +0.000008] kasansavestack+0x2c/0x5c [ +0.000011] kasansettrack+0x2c/0x40 [ +0.000008] kasansetfreeinfo+0x28/0x50 [ +0.000009] kasanslabfree+0x128/0x1d4 [ +0.000008] kasanslabfree+0x18/0x24 [ +0.000007] slabfreefreelisthook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] releasenodes+0xf0/0x16c [ +0.000009] devresreleasegroup+0x180/0x270 [ +0.000008] componentunbind+0x128/0x1e0 [ +0.000010] componentunbindall+0x1b8/0x264 [ +0.000009] mesondrvunbind+0x1a0/0x2ac [mesondrm] [ +0.000025] takedownaggregatedevice+0xb0/0x160 [ +0.000009] componentdel+0x18c/0x360 [ +0.000009] mesondwhdmiremove+0x28/0x40 [mesondwhdmi] [ +0.000012] platformremove+0x64/0xb0 [ +0.000008] deviceremove+0xb8/0x154 [ +0.000009] devicereleasedriverinternal+0x398/0x5b0 [ +0.000009] driverdetach+0xac/0x1b0 [ +0.000009] busremovedriver+0x158/0x29c [ +0.000008] driverunregister+0x70/0xb0 [ +0.000008] platformdriverunregister+0x20/0x2c [ +0.000008] mesondwhdmiplatformdriverexit+0x1c/0x30 [mesondwhdmi] [ +0.000011] dosysdeletemodule+0x288/0x400 [ +0.000010] arm64sysdeletemodule+0x5c/0x80 [ +0.000008] invokesyscall+0x74/0x260 [ +0.000008] el0svccommon.constprop.0+0xcc/0x260 [ +0.000008] doel0svc+0x50/0x70 [ +0.000007] el0svc+0x68/0x1a0 [ +0.000009] el0t64synchandler+0x11c/0x150 [ +0.000009] el0t64sync+0x18c/0x190
[ +0.000014] The buggy address belongs to the object at ffff000020c39000 ---truncated---
drm/meson: remove drm bridges at aggregate driver unbind time
In the Linux kernel, the following vulnerability has been resolved:
udp: clear skb->dev before running a sockmap verdict
On the UDP receive path skb->dev is repurposed as devscratch (the truesize/state cache set by udpsetdevscratch()), through the union { struct netdevice dev; unsigned long devscratch; } in skbuff.
When a UDP socket is in a sockmap, skdataready is skpsockverdictdataready(), which calls udpreadskb() -> recvactor() (skpsockverdictrecv) to run the attached SKSKB verdict program in softirq. If that program calls a socket-lookup helper (bpfsklookuptcp/udp, bpfskclookuptcp), bpfskclookup() does:
if (skb->dev) callernet = devnet(skb->dev);
skb->dev still holds the devscratch value (a non-NULL integer), so devnet() dereferences it as a struct netdevice and the kernel takes a general protection fault on a non-canonical address in softirq:
Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpfskclookup net/core/filter.c:7033 [inline] RIP: 0010:bpfsklookup+0x45/0x160 net/core/filter.c:7047 Call Trace: <IRQ> bpfprog4675cb904b7071f8+0x12e/0x14e bpfprogrunpinoncpu+0xc6/0x1f0 skpsockverdictrecv+0x1ba/0x350 udpreadskb+0x31a/0x370 skpsockverdictdataready+0x2e3/0x600 udpenqueuescheduleskb+0x4c8/0x650 udpv6queuercvoneskb+0x3ec/0x740 udp6unicastrcvskb+0x11d/0x140 ip6protocoldeliverrcu+0x61e/0x950 ip6inputfinish+0xa9/0x150 NFHOOK+0x286/0x2f0 ip6input+0x117/0x220 NFHOOK+0x286/0x2f0 netifreceiveskb+0x85/0x200 processbacklog+0x374/0x9a0 napipoll+0x4f/0x1c0 netrxaction+0x3b0/0x770 handlesoftirqs+0x15a/0x460 dosoftirq+0x57/0x80 </IRQ>
The rmem charge that devscratch accounted for is released by skbrecvudp() on dequeue, just above, so the scratch is dead by the time recvactor() runs. Clear skb->dev so bpfskclookup() falls back to socknet(skb->sk), which skbsetownersksafe() set just above.
In the Linux kernel, the following vulnerability has been resolved:
net: tls: fix strparser anchor skb leak on offload RX setup failure
When tlssetdeviceoffloadrx() fails at tlsdevadd(), the error path calls tlsswfreeresourcesrx() to clean up the SW context that was initialized by tlssetswoffload(). This function calls tlsswreleaseresourcesrx() (which stops the strparser via tlsstrpstop()) and tlsswfreectxrx() (which kfrees the context), but never frees the anchor skb that was allocated by allocskb(0) in tlsstrpinit().
Note that tlsswfreeresourcesrx() is exclusively used for this "failed to start offload" code path, there's no other caller.
The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use the standard strparser"), because the standard strparser doesn't try to pre-allocate an skb.
The normal close path in tlsskprotoclose() handles cleanup by calling tlsswstrparserdone() (which calls tlsstrpdone()) after dropping the socket lock, because tlsstrpdone() does cancelworksync() and the strparser work handler takes the socket lock.
In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic
kvms390pciaifenable(), kvms390pciaifdisable(), and aenhostforward() index the GAIT by manually multiplying the index with sizeof(struct zpcigaite).
Since aift->gait is already a struct zpcigaite pointer, this double-scales the offset, accessing element aisb16 instead of aisb.
This causes out-of-bounds accesses when aisb >= 32 (with ZPCINRDEVICES=512)
Fix by removing the erroneous sizeof multiplication.
drm/amdgpu/vcn4: Prevent OOB reads when parsing IB
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: remove station if connection prep fails
If connection preparation fails for MLO connections, then the interface is completely reset to non-MLD. In this case, we must not keep the station since it's related to the link of the vif being removed. Delete an existing station. Any "newsta" is already being removed, so that doesn't need changes.
This fixes a use-after-free/double-free in debugfs if that's enabled, because a vif going from MLD (and to MLD, but that's not relevant here) recreates its entire debugfs.
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix locking usage for tcon fields
We used to use the cifstcpseslock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srvlock, seslock and tclock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization.
There were still a couple of uses of cifstcpseslock to provide tcon fields. In this patch, I've replaced them with tclock.
drm/amdgpu: Fix fence put before wait in amdgpuamdkfdsubmitib
In the Linux kernel, the following vulnerability has been resolved:
bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing
struct bpfplt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.
Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in buildplt() fails to ensure that target lands on an 8-byte boundary.
This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the structure. 2. More critically, target is updated concurrently via WRITEONCE() in bpfarchtextpoke() while the JIT'd code executes ldr. On arm64, 64-bit loads/stores are only guaranteed to be single-copy atomic if they are 64-bit aligned. A misaligned target risks a torn read, causing the JIT to jump to a corrupted address.
Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpfjitbinarypackalloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in buildplt() to correctly align the target field.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix one NULL pointer dereference in smcibissgneedsync()
BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smchswq smclistenwork [smc] RIP: 0010:smcibissgneedsync+0x9e/0xd0 [smc] ... Call Trace: <TASK> smcrbufmaplink+0x211/0x2a0 [smc] smcbufcreate+0x522/0x970 [smc] smcbufcreate+0x3a/0x110 [smc] smcfindrdmav2deviceserv+0x18f/0x240 [smc] ? smcvlanbytcpsk+0x7e/0xe0 [smc] smclistenfinddevice+0x1dd/0x2b0 [smc] smclistenwork+0x30f/0x580 [smc] processonework+0x18c/0x340 workerthread+0x242/0x360 kthread+0xe7/0x220 retfromfork+0x13a/0x160 retfromforkasm+0x1a/0x30 </TASK>
If the software RoCE device is used, ibdev->dmadevice is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems.
In the Linux kernel, the following vulnerability has been resolved:
proc: use the same treatment to check proclseek as ones for procreaditer et.al
Check pde->procops->proclseek directly may cause UAF in rmmod scenario. It's a gap in procregopen() after commit 654b33ada4ab("proc: fix UAF in procgetinode()"). Followed by AI Viro's suggestion, fix it in same manner.
f2fs: compress: fix UAF of f2fsinodeinfo in f2fsfreedic
In the Linux kernel, the following vulnerability has been resolved:
fs: export anoninodemakesecureinode() and fix secretmem LSM bypass
Export anoninodemakesecureinode() to allow KVM guestmemfd to create anonymous inodes with proper security context. This replaces the current pattern of calling allocanoninode() followed by inodeinitsecurityanon() for creating security context manually.
This change also fixes a security regression in secretmem where the SPRIVATE flag was not cleared after allocanoninode(), causing LSM/SELinux checks to be bypassed for secretmem file descriptors.
As guestmemfd currently resides in the KVM module, we need to export this symbol for use outside the core kernel. In the future, guestmemfd might be moved to core-mm, at which point the symbols no longer would have to be exported. When/if that happens is still unclear.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential deadlock when reconnecting channels
Fix cifssignalcifsdforreconnect() to take the correct lock order and prevent the following deadlock from happening
====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W ------------------------------------------------------ cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcpses->srvlock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0x134/0x200
but task is already holding lock: ffff888119c64330 (&retbuf->chanlock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0xcf/0x200
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&retbuf->chanlock){+.+.}-{3:3}: validatechain+0x1cf/0x270 lockacquire+0x60e/0x780 lockacquire.part.0+0xb4/0x1f0 rawspinlock+0x2f/0x40 cifssetupsession+0x81/0x4b0 cifsgetsmbses+0x771/0x900 cifsmountgetsession+0x7e/0x170 cifsmount+0x92/0x2d0 cifssmb3domount+0x161/0x460 smb3gettree+0x55/0x90 vfsgettree+0x46/0x180 donewmount+0x1b0/0x2e0 pathmount+0x6ee/0x740 domount+0x98/0xe0 dosysmount+0x148/0x180 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x76/0x7e
-> #1 (&retbuf->seslock){+.+.}-{3:3}: validatechain+0x1cf/0x270 lockacquire+0x60e/0x780 lockacquire.part.0+0xb4/0x1f0 rawspinlock+0x2f/0x40 cifsmatchsuper+0x101/0x320 sget+0xab/0x270 cifssmb3domount+0x1e0/0x460 smb3gettree+0x55/0x90 vfsgettree+0x46/0x180 donewmount+0x1b0/0x2e0 pathmount+0x6ee/0x740 domount+0x98/0xe0 dosysmount+0x148/0x180 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x76/0x7e
-> #0 (&tcpses->srvlock){+.+.}-{3:3}: checknoncircular+0x95/0xc0 checkprevadd+0x115/0x2f0 validatechain+0x1cf/0x270 lockacquire+0x60e/0x780 lockacquire.part.0+0xb4/0x1f0 rawspinlock+0x2f/0x40 cifssignalcifsdforreconnect+0x134/0x200 cifsreconnect+0x8f/0x500 cifshandlestandard+0x112/0x280 cifsdemultiplexthread+0x64d/0xbc0 kthread+0x2f7/0x310 retfromfork+0x2a/0x230 retfromforkasm+0x1a/0x30
other info that might help us debug this:
Chain exists of: &tcpses->srvlock --> &retbuf->seslock --> &retbuf->chanlock
Possible unsafe locking scenario:
CPU0 CPU1 ---- ---- lock(&retbuf->chanlock); lock(&retbuf->seslock); lock(&retbuf->chanlock); lock(&tcpses->srvlock);
DEADLOCK
3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifstcpseslock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0x7b/0x200 #1: ffff888119c64060 (&retbuf->seslock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0x9c/0x200 #2: ffff888119c64330 (&retbuf->chanlock){+.+.}-{3:3}, at: cifssignalcifsdforreconnect+0xcf/0x200
In the Linux kernel, the following vulnerability has been resolved:
netsched: ets: fix a race in etsqdiscchange()
Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 [1]: lock root [2]: qdisctreeflushbacklog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisctreereducebacklog() | [4]: qdiscput()
This can be abused to underflow a parent's qlen.
Calling qdiscpurgequeue() instead of qdisctreeflushbacklog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.