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.

In the Linux kernel, the following vulnerability has been resolved:

spi: fix statistics allocation

The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.

Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).

bpf: Fix a UAF issue in bpftrampolinelinkcgroupshim

In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtkethsoc: Reset prog ptr to oldprog in case of error in mtkxdpsetup()

Reset eBPF program pointer to oldprog and do not decrease its ref-count if mtkopen routine in mtkxdpsetup() fails.

In the Linux kernel, the following vulnerability has been resolved:

Input: mtk-pmic-keys - fix possible null pointer dereference

In mtkpmickeysprobe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer.

Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.

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:

PCI: brcmstb: Fix error path after a call to regulatorbulkget()

If the regulatorbulkget() returns an error and no regulators are created, we need to set their number to zero.

If we don't do this and the PCIe link up fails, a call to the regulatorbulkfree() will result in a kernel panic.

While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from addbus().

[kwilczynski: commit log, use comma in the message to match style with other similar messages]

In the Linux kernel, the following vulnerability has been resolved:

remoteproc: core: Fix idafree call while not allocated

In the rprocalloc() function, on error, putdevice(&rproc->dev) is called, leading to the call of the rproctyperelease() function. An error can occurs before idaalloc is called.

In such case in rproctyperelease(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. idafree() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 idafree+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] idafree called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panelorisetechotm8009a dwmipidsistm(+) gpusched dwmipidsi stm32rproc stm32crc32 stm32ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: eventsunbound deferredprobeworkfunc [ 4.242504] Call trace: [ 4.242522] unwindbacktrace from showstack+0x10/0x14 [ 4.250218] showstack from dumpstacklvl+0x50/0x64 [ 4.255274] dumpstacklvl from warn+0x80/0x12c [ 4.260134] warn from warnslowpathfmt+0x114/0x188 [ 4.265199] warnslowpathfmt from idafree+0x100/0x164 [ 4.270565] idafree from rproctyperelease+0x38/0x60 [ 4.275832] rproctyperelease from devicerelease+0x30/0xa0 [ 4.281601] devicerelease from kobjectput+0xc4/0x294 [ 4.286762] kobjectput from rprocalloc.part.0+0x208/0x28c [ 4.292430] rprocalloc.part.0 from devmrprocalloc+0x80/0xc4 [ 4.298393] devmrprocalloc from stm32rprocprobe+0xd0/0x844 [stm32rproc] [ 4.305575] stm32rprocprobe [stm32rproc] from platformprobe+0x5c/0xbc

Calling idaalloc earlier in rprocalloc ensures that the rproc->index is properly set.

In the Linux kernel, the following vulnerability has been resolved:

mm: shrinker: fix NULL pointer dereference in debugfs

shrinkerdebugfsadd() creates both "count" and "scan" debugfs files unconditionally.

That assumes every shrinker implements both countobjects() and scanobjects(), which is not guaranteed. For example, the xen-backend shrinker sets countobjects() but leaves scanobjects() NULL, so writing to its scan file calls through a NULL function pointer and panics the kernel:

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. Call Trace: <TASK> shrinkerdebugfsscanwrite+0x12e/0x270 fullproxywrite+0x5f/0x90 vfswrite+0xde/0x420 ? filpflush+0x75/0x90 ? filpclose+0x1d/0x30 ? dodup2+0xb8/0x120 ksyswrite+0x68/0xf0 ? filpflush+0x75/0x90 dosyscall64+0xb3/0x5b0 entrySYSCALL64afterhwframe+0x76/0x7e

The count path has the same issue in principle if a shrinker omits countobjects().

To fix it, only create "count" and "scan" debugfs files when the corresponding callbacks are present.

In the Linux kernel, the following vulnerability has been resolved:

mm/shrinker: do not hold RCU lock in shrinkerdebugfscountshow()

Reading the debugfs "count" file of a memcg-aware shrinker can sleep inside an RCU read-side critical section:

BUG: sleeping function called from invalid context at kernel/cgroup/rstat.c:421 RCU nest depth: 1, expected: 0 cssrstatflush memcgroupflushstats zswapshrinkercount shrinkerdebugfscountshow

shrinkerdebugfscountshow() invokes the ->countobjects() callback under rcureadlock(). The zswap callback flushes memcg stats via cssrstatflush(), which may sleep, so it must not run under RCU.

The RCU lock is not needed here. memcgroupiter() takes RCU internally and returns a memcg holding a css reference (dropped on the next iteration or by memcgroupiterbreak()), so the memcg stays alive without it. The shrinker is kept alive by the open debugfs file: shrinkerfree() removes the debugfs entries via debugfsremoverecursive(), which waits for in-flight readers to drain, before callrcu(..., shrinkerfreercucb). The sibling "scan" handler already invokes the sleeping ->scanobjects() callback with no RCU section.

Drop the rcureadlock()/rcureadunlock().

In the Linux kernel, the following vulnerability has been resolved:

nvmet-auth: validate reply message payload bounds against transfer length

nvmetauthreply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.

A malicious NVMe-oF initiator can craft a DHCHAPREPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2hl) or performs the host response memcmp.

With DH authentication configured, the OOB pointer is passed directly to sginitone() and read by cryptokppcomputesharedsecret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.

Add bounds validation ensuring sizeof(data) + 2hl + dhvlen <= tl before any access to the variable-length fields.

Discovered by Atuin - Automated Vulnerability Discovery Engine.

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().

In the Linux kernel, the following vulnerability has been resolved:

NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR

When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:

Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]

Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.

fbdev: fbcon: fix out-of-bounds read in errout of fbcondosetfont()

9p: avoid putting oldfid in p9clientwalk() error path

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:

wifi: ath11k: mhi: fix potential memory leak in ath11kmhiregister()

mhialloccontroller() allocates a memory space for mhictrl. When gets some error, mhictrl should be freed with mhifreecontroller(). But when ath11kmhireadaddrfromdt() fails, the function returns without calling mhifreecontroller(), which will lead to a memory leak.

We can fix it by calling mhifreecontroller() when ath11kmhireadaddrfromdt() fails.

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:

f2fs: fix to do sanity check on destination blkaddr during recovery

As Wenqing Liu reported in bugzilla:

https://bugzilla.kernel.org/showbug.cgi?id=216456

loop5: detected capacity change from 0 to 131072 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): recoverinode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recoverdata: ino = 6 (isize: recover) err = 0 F2FS-fs (loop5): Bitmap was wrongly set, blk:5634 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198 RIP: 0010:updatesitentry+0xa55/0x10b0 [f2fs] Call Trace: <TASK> f2fsdoreplaceblock+0xa98/0x1890 [f2fs] f2fsreplaceblock+0xeb/0x180 [f2fs] recoverdata+0x1a69/0x6ae0 [f2fs] f2fsrecoverfsyncdata+0x120d/0x1fc0 [f2fs] f2fsfillsuper+0x4665/0x61e0 [f2fs] mountbdev+0x2cf/0x3b0 legacygettree+0xed/0x1d0 vfsgettree+0x81/0x2b0 pathmount+0x47e/0x19d0 domount+0xce/0xf0 x64sysmount+0x12c/0x1a0 dosyscall64+0x38/0x90 entrySYSCALL64afterhwframe+0x63/0xcd

If we enable CONFIGF2FSCHECKFS config, it will trigger a kernel panic instead of warning.

The root cause is: in fuzzed image, SIT table is inconsistent with inode mapping table, result in triggering such warning during SIT table update.

This patch introduces a new flag DATAGENERICENHANCEUPDATE, w/ this flag, data block recovery flow can check destination blkaddr's validation in SIT table, and skip f2fsreplaceblock() to avoid inconsistent status.

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: ISO: drop ISOEND frames received without prior ISOSTART

ISO data PDUs carry a packet-boundary flag indicating START, CONT, END or SINGLE. The ISOCONT branch of isorecv() guards against a missing ISOSTART by checking conn->rxlen before touching conn->rxskb, but ISOEND does not.

If a peer sends an ISOEND as the first packet on a fresh ISO connection, conn->rxskb is still NULL and conn->rxlen is zero, so skbput(conn->rxskb, ...) dereferences NULL and oopses. For BIS, where receivers sync to a broadcaster without pairing, any broadcaster on the air can trigger this.

Mirror the ISOCONT check at the top of ISOEND so a stray end fragment is logged and dropped instead of crashing the host.

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.