In the Linux kernel, the following vulnerability has been resolved:
iomap: iomap: fix memory corruption when recording errors during writeback
Every now and then I see this crash on arm64:
Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dmthinpool dmpersistentdata XFS (dm-0): Metadata I/O Error (0x1) detected at xfstransreadbufmap+0x1ec/0x590 [xfs] (fs/xfs/xfstransbuf.c:296). dmbioprison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfsimaplookup: xfsiallocreadagi() returned error -5, agno 0 dmbufio dmlogwrites xfs nftchainnat xtREDIRECT nfnat nfconntrack nfdefragipv6 nfdefragipv4 ip6tREJECT potentially unexpected fatal signal 6. nfrejectipv6 potentially unexpected fatal signal 6. iptREJECT nfrejectipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsecgsskrb5 authrpcgss xttcpudp ipsethaship ipsethashnet xtset nftcompat ipsethashmac ipset nftables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) iptables pc : 000003fd6d7df200 xtables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wbworkfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseqset+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : filemapsetwberr+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseqset+0x1c/0x100 filemapsetwberr+0x24/0xe0 iomapdowritepage+0x5e4/0xd5c writecachepages+0x208/0x674 iomapwritepages+0x34/0x60 xfsvmwritepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---
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.
bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing
In the Linux kernel, the following vulnerability has been resolved:
staging: media: atomisp: Fix stack buffer overflow in gmingetvarint()
When gmingetconfigvar() calls efi.getvariable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow:
1. gmingetconfigvar() does not return the proper error code when efi.getvariable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure.
2. When efi.getvariable() returns EFIBUFFERTOOSMALL, it updates outlen to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmingetvarint() believes the call succeeded.
The caller gmingetvarint() then performs: - Allocates val[CFGVARNAMEMAX + 1] (65 bytes) on stack - Calls gmingetconfigvar(dev, isgmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.getvariable() sets len=requiredsize - Due to bug #1, thinks call succeeded with len=requiredsize - Executes val[len] = 0, writing past end of 65-byte stack buffer
This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution.
Fix the bug by returning proper error codes from gmingetconfigvar() based on EFI status instead of stale 'ret' value.
The gmingetvarint() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack.
In the Linux kernel, the following vulnerability has been resolved:
rv: Use strings in da monitors tracepoints
Using DA monitors tracepoints with KASAN enabled triggers the following warning:
BUG: KASAN: global-out-of-bounds in dotraceeventraweventeventdamonitor+0xd6/0x1a0 Read of size 32 at addr ffffffffaada8980 by task ... Call Trace: <TASK> [...] dotraceeventraweventeventdamonitor+0xd6/0x1a0 ? pfxdotraceeventraweventeventdamonitor+0x10/0x10 ? traceeventsncid+0x83/0x200 traceeventsncid+0x163/0x200 [...] The buggy address belongs to the variable: automatonsnep+0x4e0/0x5e0
This is caused by the tracepoints reading 32 bytes array instead of string from the automata definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g. the next automaton's data in this case). The error is harmless as, while printing the string, we stop at the null terminator, but it should still be fixed.
Use the string facilities while defining the tracepoints to avoid reading out of bound memory.
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:
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