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

HID: letsketch: fix UAF on inrangetimer at driver unbind

letsketchdriver does not provide a .remove callback, but letsketchprobe() arms a per-device timer:

timersetup(&data->inrangetimer, letsketchinrangetimeout, 0);

The timer is re-armed from letsketchrawevent() with a 100 ms timeout on every pen-in-range report, and its callback dereferences data->inputtablet to deliver a synthetic BTNTOOLPEN release.

letsketchdata is allocated with devmkzalloc(), and its inputdev fields are devm-allocated via letsketchsetupinputtablet(). On device unbind (USB unplug or rmmod), the HID core runs its default teardown and devm cleanup frees both letsketchdata and the input devices. Because no .remove callback exists, nothing drains the timer first: if rawevent armed it within ~100 ms of the unbind, the pending timer fires on freed memory. This is a UAF read of data and of data->inputtablet, followed by inputreportkey() / inputsync() into the freed inputdev.

The same problem can occur on the probe error path: if hidhwstart() enabled I/O on an always-poll-quirk device and then failed, rawevent may have armed the timer before devm releases data.

Fix by adding a .remove callback that calls hidhwstop() first. hidhwstop() synchronously kills the URBs that deliver rawevent(), so once it returns no path can re-arm the timer. timershutdownsync() then drains any in-flight callback and permanently disables further modtimer() calls. Apply the same timershutdownsync() in the probe error path so the timer is guaranteed not to outlive data.

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

net: ifb: report ethtool stats over numtxqueues

ifbdevinit() allocates dp->txprivate to dev->numtxqueues entries via kzallocobjs(txp, dev->numtxqueues). Both IFB per-queue RX and TX stats live in those entries: ifbxmit() updates txp->rxstats using the skb queue mapping, ifbritasklet() updates txp->txstats, and ifbstats64() aggregates both over dev->numtxqueues.

The ethtool stats callbacks instead size and walk the per-queue stats with dev->realnumrxqueues and dev->realnumtxqueues. With an asymmetric device where the RX queue count exceeds the TX queue count, for example:

ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb ethtool -S ifb10

ifbgetethtoolstats() indexes past the txprivate allocation and copies adjacent slab data through ETHTOOLGSTATS.

Use dev->numtxqueues consistently for the stats strings, the stats count, and the stats data walks. This reports one RX stats group and one TX stats group for each backing ifbqprivate entry, which is the queue set IFB can actually populate.

Reproduced under UML+KASAN at v7.1-rc2:

BUG: KASAN: slab-out-of-bounds in ifbfillstatsdata+0x3c/0xae Read of size 8 at addr 0000000062dbd228 by task ethtool/36 ifbfillstatsdata+0x3c/0xae ifbgetethtoolstats+0xc0/0x129 devethtool+0x1ca5/0x363c devethtool+0x123/0x1b3 devioctl+0x56c/0x744 sockdoioctl+0x15f/0x1b2 sockioctl+0x4d5/0x50a sysioctl+0xd8b/0xde9

With the patch applied, the same UML+KASAN repro is silent and ethtool -S ifb10 reports only the stats backed by the single allocated txprivate entry.

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

erofs: fix use-after-free on sbi->syncdecompress

zerofsdecompresskickoff() can race with filesystem unmount, causing a use-after-free on sbi->syncdecompress.

When I/O completes, zerofsendio() calls zerofsdecompresskickoff() to queue zerofsdecompressqueuework() asynchronously. Then, after all folios are unlocked, unmount workflow can proceed and sbi will be freed before accessing to sbi->syncdecompress.

Thread (unmount) I/O completion kworker queuework zerofsdecompressqueuework (all folios are unlocked) cleanupmnt .. erofskillsb erofssbfree kfree(sbi) access sbi->syncdecompress // UAF!!

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

Revert "net/smc: Introduce TCP ULP support"

This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.

As reported by Al Viro, the TCP ULP support for SMC is fundamentally broken. The implementation attempts to convert an active TCP socket into an SMC socket by modifying the underlying struct file, dentry, and inode in-place, which violates core VFS invariants that assume these structures are immutable for an open file, creating a risk of use after free errors and general system instability.

Given the severity of this design flaw and the fact that cleaner alternatives (e.g., LDPRELOAD, BPF) exist for legacy application transparency, the correct course of action is to remove this feature entirely.

exit: prevent preemption of oopsing TASKDEAD task

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

erofs: fix inline data read failure for ztailpacking pclusters

Compressed folios for ztailpacking pclusters must be valid before adding these pclusters to I/O chains. Otherwise, zerofsdecompresspcluster() may assume they are already valid and then trigger a NULL pointer dereference.

It is somewhat hard to reproduce because the inline data is in the same block as the tail of the compressed indexes, which are usually read just before. However, it may still happen if a fatal signal arrives while readmappingfolio() is running, as shown below:

erofs: (device dm-1): zerofspclusterbegin: failed to get inline data -4 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008

...

pc : zerofsdecompressqueue+0x4c8/0xa14 lr : zerofsdecompressqueue+0x160/0xa14 sp : ffffffc08b3eb3a0 x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000 x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001 x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700 x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098 x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004 x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9 x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: zerofsdecompressqueue+0x4c8/0xa14 zerofsrunqueue+0x908/0x97c zerofsreadfolio+0x128/0x228 filemapreadfolio+0x68/0x128 filemapgetpages+0x44c/0x8b4 filemapread+0x12c/0x5b8 genericfilereaditer+0x4c/0x15c doiterreadvwritev+0x188/0x1e0 vfsiterread+0xac/0x1a4 backingfilereaditer+0x170/0x34c ovlreaditer+0xf0/0x140 vfsread+0x28c/0x344 ksysread+0x80/0xf0 arm64sysread+0x24/0x34 invokesyscall+0x60/0x114 el0svccommon+0x88/0xe4 doel0svc+0x24/0x30 el0svc+0x40/0xa8 el0t64synchandler+0x70/0xbc el0t64sync+0x1bc/0x1c0

Fix this by reading the inline data before allocating and adding the pclusters to the I/O chains.

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

Bluetooth: hcievent: fix potential UAF in hcileremoteconnparamreqevt

hciconn lookup and field access must be covered by hdev lock in hcileremoteconnparamreqevt, otherwise it's possible it is freed concurrently.

Extend the hcidevlock critical section to cover all conn usage.

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

iavf: fix out-of-bounds writes in iavfgetethtoolstats()

iavf incorrectly uses realnumtxqueues for ETHSSSTATS. Since the value could change in runtime, we should use numtxqueues instead.

Moreover iavfgetethtoolstats() uses numactivequeues while iavfgetssetcount() and iavfgetstatstrings() use realnumtxqueues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1].

For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3:

Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S) iavfsetchannels() ... iavfallocqueues() -> numactivequeues = 8 iavfschedulefinishconfig() iavfgetssetcount() realnumtxqueues: 1 -> buffer for 1 queue iavfgetethtoolstats() numactivequeues: 8 -> out-of-bounds! iavffinishconfig() -> realnumtxqueues = 8

Use immutable numtxqueues in all related functions to avoid the issue.

[1] BUG: KASAN: vmalloc-out-of-bounds in iavfaddoneethtoolstat+0x200/0x270 Write of size 8 at addr ffffc900031c9080 by task ethtool/5800

CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x6f/0xb0 printreport+0x170/0x4f3 kasanreport+0xe1/0x180 iavfaddoneethtoolstat+0x200/0x270 iavfgetethtoolstats+0x14c/0x2e0 devethtool+0x3d0c/0x5830 devethtool+0x12d/0x270 devioctl+0x53c/0xe30 sockdoioctl+0x1a9/0x270 sockioctl+0x3d4/0x5e0 x64sysioctl+0x137/0x1c0 dosyscall64+0xf3/0x690 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f7da0e6e36d ... </TASK>

The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at devethtool+0x3cc9/0x5830 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88813a013de0 pfn:0x13a013 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

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

net: bonding: fix use-after-free in bondxmitbroadcast()

bondxmitbroadcast() reuses the original skb for the last slave (determined by bondislastslave()) and clones it for others. Concurrent slave enslave/release can mutate the slave list during RCU-protected iteration, changing which slave is "last" mid-loop. This causes the original skb to be double-consumed (double-freed).

Replace the racy bondislastslave() check with a simple index comparison (i + 1 == slavescount) against the pre-snapshot slave count taken via READONCE() before the loop. This preserves the zero-copy optimization for the last slave while making the "last" determination stable against concurrent list mutations.

The UAF can trigger the following crash:

================================================================== BUG: KASAN: slab-use-after-free in skbclone Read of size 8 at addr ffff888100ef8d40 by task exploit/147

CPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:123) printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:597) skbclone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108) bondxmitbroadcast (drivers/net/bonding/bondmain.c:5334) bondstartxmit (drivers/net/bonding/bondmain.c:5567 drivers/net/bonding/bondmain.c:5593) devhardstartxmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887) devqueuexmit (include/linux/netdevice.h:3601 net/core/dev.c:4838) ip6finishoutput2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6output.c:136) ip6finishoutput (net/ipv6/ip6output.c:208 net/ipv6/ip6output.c:219) ip6output (net/ipv6/ip6output.c:250) ip6sendskb (net/ipv6/ip6output.c:1985) udpv6sendskb (net/ipv6/udp.c:1442) udpv6sendmsg (net/ipv6/udp.c:1733) syssendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206) x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>

Allocated by task 147:

Freed by task 147:

The buggy address belongs to the object at ffff888100ef8c80 which belongs to the cache skbuffheadcache of size 224 The buggy address is located 192 bytes inside of freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)

Memory state around the buggy address: ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================

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

drm/msm/dp: fix memory corruption with too many bridges

Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges.

Patchwork: https://patchwork.freedesktop.org/patch/502664/

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

Bluetooth: use RCU for hciconnparams and iterate safely in hcisync

hciupdateacceptlistsync iterates over hdev->pendleconns and hdev->pendlereports, and waits for controller events in the loop body, without holding hdev lock.

Meanwhile, these lists and the items may be modified e.g. by lescancleanup. This can invalidate the list cursor or any other item in the list, resulting to invalid behavior (eg use-after-free).

Use RCU for the hciconnparams action lists. Since the loop bodies in hcisync block and we cannot use RCU or hdev->lock for the whole loop, copy list items first and then iterate on the copy. Only the flags field is written from elsewhere, so READONCE/WRITEONCE should guarantee we read valid values.

Free params everywhere with hciconnparamsfree so the cleanup is guaranteed to be done properly.

This fixes the following, which can be triggered e.g. by BlueZ new mgmt-tester case "Add + Remove Device Nowait - Success", or by changing hcilesetcigparams to always return false, and running iso-tester:

================================================================== BUG: KASAN: slab-use-after-free in hciupdatepassivescansync (net/bluetooth/hcisync.c:2536 net/bluetooth/hcisync.c:2723 net/bluetooth/hcisync.c:2841) Read of size 8 at addr ffff888001265018 by task kworker/u3:0/32

Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstacklvl (./arch/x86/include/asm/irqflags.h:134 lib/dumpstack.c:107) printreport (mm/kasan/report.c:320 mm/kasan/report.c:430) ? virtaddrvalid (./include/linux/mmzone.h:1915 ./include/linux/mmzone.h:2011 arch/x86/mm/physaddr.c:65) ? hciupdatepassivescansync (net/bluetooth/hcisync.c:2536 net/bluetooth/hcisync.c:2723 net/bluetooth/hcisync.c:2841) kasanreport (mm/kasan/report.c:538) ? hciupdatepassivescansync (net/bluetooth/hcisync.c:2536 net/bluetooth/hcisync.c:2723 net/bluetooth/hcisync.c:2841) hciupdatepassivescansync (net/bluetooth/hcisync.c:2536 net/bluetooth/hcisync.c:2723 net/bluetooth/hcisync.c:2841) ? pfxhciupdatepassivescansync (net/bluetooth/hcisync.c:2780) ? mutexlock (kernel/locking/mutex.c:282) ? pfxmutexlock (kernel/locking/mutex.c:282) ? pfxmutexunlock (kernel/locking/mutex.c:538) ? pfxupdatepassivescansync (net/bluetooth/hcisync.c:2861) hcicmdsyncwork (net/bluetooth/hcisync.c:306) processonework (./arch/x86/include/asm/preempt.h:27 kernel/workqueue.c:2399) workerthread (./include/linux/list.h:292 kernel/workqueue.c:2538) ? pfxworkerthread (kernel/workqueue.c:2480) kthread (kernel/kthread.c:376) ? pfxkthread (kernel/kthread.c:331) retfromfork (arch/x86/entry/entry64.S:314) </TASK>

Allocated by task 31: kasansavestack (mm/kasan/common.c:46) kasansettrack (mm/kasan/common.c:52) kasankmalloc (mm/kasan/common.c:374 mm/kasan/common.c:383) hciconnparamsadd (./include/linux/slab.h:580 ./include/linux/slab.h:720 net/bluetooth/hcicore.c:2277) hciconnectlescan (net/bluetooth/hciconn.c:1419 net/bluetooth/hciconn.c:1589) hciconnectcis (net/bluetooth/hciconn.c:2266) isoconnectcis (net/bluetooth/iso.c:390) isosockconnect (net/bluetooth/iso.c:899) sysconnect (net/socket.c:2003 net/socket.c:2020) x64sysconnect (net/socket.c:2027) dosyscall64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:120)

Freed by task 15: kasansavestack (mm/kasan/common.c:46) kasansettrack (mm/kasan/common.c:52) kasansavefreeinfo (mm/kasan/generic.c:523) kasanslabfree (mm/kasan/common.c:238 mm/kasan/common.c:200 mm/kasan/common.c:244) kmemcachefree (mm/slub.c:1807 mm/slub.c:3787 mm/slub.c:3800) hciconnparamsdel (net/bluetooth/hcicore.c:2323) lescancleanup (net/bluetooth/hciconn.c:202) processonework (./arch/x86/include/asm/preempt. ---truncated---

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

f2fs: fix the assign logic of iocb

commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint") introduces iocb field in 'f2fsdirectIOenter' trace event And it only assigns the pointer and later it accesses its field in trace print log.

Unable to handle kernel paging request at virtual address ffffffc04cef3d30 Mem abort info: ESR = 0x96000007 EC = 0x25: DABT (current EL), IL = 32 bits

pc : tracerawoutputf2fsdirectIOenter+0x54/0xa4 lr : tracerawoutputf2fsdirectIOenter+0x2c/0xa4 sp : ffffffc0443cbbd0 x29: ffffffc0443cbbf0 x28: ffffff8935b120d0 x27: ffffff8935b12108 x26: ffffff8935b120f0 x25: ffffff8935b12100 x24: ffffff8935b110c0 x23: ffffff8935b10000 x22: ffffff88859a936c x21: ffffff88859a936c x20: ffffff8935b110c0 x19: ffffff8935b10000 x18: ffffffc03b195060 x17: ffffff8935b11e76 x16: 00000000000000cc x15: ffffffef855c4f2c x14: 0000000000000001 x13: 000000000000004e x12: ffff0000ffffff00 x11: ffffffef86c350d0 x10: 00000000000010c0 x9 : 000000000fe0002c x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : 0000000002000000 x5 : ffffff8935b11e9a x4 : 0000000000006250 x3 : ffff0a00ffffff04 x2 : 0000000000000002 x1 : ffffffef86a0a31f x0 : ffffff8935b10000 Call trace: tracerawoutputf2fsdirectIOenter+0x54/0xa4 printtracefmt+0x9c/0x138 printtraceline+0x154/0x254 tracingreadpipe+0x21c/0x380 vfsread+0x108/0x3ac ksysread+0x7c/0xec arm64sysread+0x20/0x30 invokesyscall+0x60/0x150 el0svccommon.llvm.1237943816091755067+0xb8/0xf8 doel0svc+0x28/0xa0

Fix it by copying the required variables for printing and while at it fix the similar issue at some other places in the same file.

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

ACPI: pfrupdate: Fix the driver update version check

The security-version-number check should be used rather than the runtime version check for driver updates.

Otherwise, the firmware update would fail when the update binary had a lower runtime version number than the current one.

[ rjw: Changelog edits ]

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

gve: prevent ethtool ops after shutdown

A crash can occur if an ethtool operation is invoked after shutdown() is called.

shutdown() is invoked during system shutdown to stop DMA operations without performing expensive deallocations. It is discouraged to unregister the netdev in this path, so the device may still be visible to userspace and kernel helpers.

In gve, shutdown() tears down most internal data structures. If an ethtool operation is dispatched after shutdown(), it will dereference freed or NULL pointers, leading to a kernel panic. While graceful shutdown normally quiesces userspace before invoking the reboot syscall, forced shutdowns (as observed on GCP VMs) can still trigger this path.

Fix by calling netifdevicedetach() in shutdown(). This marks the device as detached so the ethtool ioctl handler will skip dispatching operations to the driver.

Bluetooth: hcisync: fix double free in 'hcidiscoveryfilterclear()'

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

net: usb: lan78xx: fix WARN in netifnapidellocked on disconnect

Remove redundant netifnapidel() call from disconnect path.

A WARN may be triggered in netifnapidellocked() during USB device disconnect:

WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 netifnapidellocked+0x2b4/0x350

This happens because netifnapidel() is called in the disconnect path while NAPI is still enabled. However, it is not necessary to call netifnapidel() explicitly, since unregisternetdev() will handle NAPI teardown automatically and safely. Removing the redundant call avoids triggering the warning.

Full trace: lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV lan78xx 1-1:1.0 enu1: Link is Down lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 netifnapidellocked+0x2b4/0x350 Modules linked in: flexcan candev fuse CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT Hardware name: SKOV IMX8MP CPU revC - bd500 (DT) Workqueue: usbhubwq hubevent pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : netifnapidellocked+0x2b4/0x350 lr : netifnapidellocked+0x7c/0x350 sp : ffffffc085b673c0 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000 Call trace: netifnapidellocked+0x2b4/0x350 (P) lan78xxdisconnect+0xf4/0x360 usbunbindinterface+0x158/0x718 deviceremove+0x100/0x150 devicereleasedriverinternal+0x308/0x478 devicereleasedriver+0x1c/0x30 busremovedevice+0x1a8/0x368 devicedel+0x2e0/0x7b0 usbdisabledevice+0x244/0x540 usbdisconnect+0x220/0x758 hubevent+0x105c/0x35e0 processonework+0x760/0x17b0 workerthread+0x768/0xce8 kthread+0x3bc/0x690 retfromfork+0x10/0x20 irq event stamp: 211604 hardirqs last enabled at (211603): [<ffffffc0828cc9ec>] rawspinunlockirqrestore+0x84/0x98 hardirqs last disabled at (211604): [<ffffffc0828a9a84>] el1dbg+0x24/0x80 softirqs last enabled at (211296): [<ffffffc080095f10>] handlesoftirqs+0x820/0xbc8 softirqs last disabled at (210993): [<ffffffc080010288>] dosoftirq+0x18/0x20 ---[ end trace 0000000000000000 ]--- lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0

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

scsi: megaraidsas: Fix invalid node index

On a system with DRAM interleave enabled, out-of-bound access is detected:

megaraidsas 0000:3f:00.0: requested/available msix 128/128 pollqueue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [1024]' dumpstacklvl+0x5d/0x80 ubsanepilogue+0x5/0x2b ubsanhandleoutofbounds.cold+0x46/0x4b megasasallocirqvectors+0x149/0x190 [megaraidsas] megasasprobeone.cold+0xa4d/0x189c [megaraidsas] localpciprobe+0x42/0x90 pcideviceprobe+0xdc/0x290 reallyprobe+0xdb/0x340 driverprobedevice+0x78/0x110 driverprobedevice+0x1f/0xa0 driverattach+0xba/0x1c0 busforeachdev+0x8b/0xe0 busadddriver+0x142/0x220 driverregister+0x72/0xd0 megasasinit+0xdf/0xff0 [megaraidsas] dooneinitcall+0x57/0x310 doinitmodule+0x90/0x250 initmodulefromfile+0x85/0xc0 idempotentinitmodule+0x114/0x310 x64sysfinitmodule+0x65/0xc0 dosyscall64+0x82/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

Fix it accordingly.

ax25: fix incorrect devtracker usage

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

regulator: max20086: fix invalid memory access

max20086parseregulatorsdt() calls ofregulatormatch() using an array of struct ofregulatormatch allocated on the stack for the matches argument.

ofregulatormatch() calls devmofregulatorputmatches(), which calls devresalloc() to allocate a struct devmofregulatormatches which will be de-allocated using devmofregulatorputmatches().

struct devmofregulatormatches is populated with the stack allocated matches array.

If the device fails to probe, devmofregulatorputmatches() will be called and will try to call ofnodeput() on that stack pointer, generating the following dmesg entries:

max20086 6-0028: Failed to read DEVICEID reg: -121 kobject: '\xc0$\xa5\x03' (000000002cebcb7a): is not initialized, yet kobjectput() is being called.

Followed by a stack trace matching the call flow described above.

Switch to allocating the matches array using devmkcalloc() to avoid accessing the stack pointer long after it's out of scope.

This also has the advantage of allowing multiple max20086 to probe without overriding the data stored inside the global ofregulatormatch.

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

Bluetooth: HCI: Fix global-out-of-bounds

To loop a variable-length array, hciinitstagesync(stage) considers that stage[i] is valid as long as stage[i-1].func is valid. Thus, the last element of stage[].func should be intentionally invalid as hciinit0[], leinit2[], and others did. However, ampinit1[] and ampinit2[] have no invalid element, letting hciinitstagesync() keep accessing ampinit1[] over its valid range. This patch fixes this by adding {} in the last of ampinit1[] and ampinit2[].

================================================================== BUG: KASAN: global-out-of-bounds in hcidevopensync ( /v6.2-bzimage/net/bluetooth/hcisync.c:3154 /v6.2-bzimage/net/bluetooth/hcisync.c:3343 /v6.2-bzimage/net/bluetooth/hcisync.c:4418 /v6.2-bzimage/net/bluetooth/hcisync.c:4609 /v6.2-bzimage/net/bluetooth/hcisync.c:4689) Read of size 8 at addr ffffffffaed1ab70 by task kworker/u5:0/1032 CPU: 0 PID: 1032 Comm: kworker/u5:0 Not tainted 6.2.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04 Workqueue: hci1 hcipoweron Call Trace: <TASK> dumpstacklvl (/v6.2-bzimage/lib/dumpstack.c:107 (discriminator 1)) printreport (/v6.2-bzimage/mm/kasan/report.c:307 /v6.2-bzimage/mm/kasan/report.c:417) ? hcidevopensync (/v6.2-bzimage/net/bluetooth/hcisync.c:3154 /v6.2-bzimage/net/bluetooth/hcisync.c:3343 /v6.2-bzimage/net/bluetooth/hcisync.c:4418 /v6.2-bzimage/net/bluetooth/hcisync.c:4609 /v6.2-bzimage/net/bluetooth/hcisync.c:4689) kasanreport (/v6.2-bzimage/mm/kasan/report.c:184 /v6.2-bzimage/mm/kasan/report.c:519) ? hcidevopensync (/v6.2-bzimage/net/bluetooth/hcisync.c:3154 /v6.2-bzimage/net/bluetooth/hcisync.c:3343 /v6.2-bzimage/net/bluetooth/hcisync.c:4418 /v6.2-bzimage/net/bluetooth/hcisync.c:4609 /v6.2-bzimage/net/bluetooth/hcisync.c:4689) hcidevopensync (/v6.2-bzimage/net/bluetooth/hcisync.c:3154 /v6.2-bzimage/net/bluetooth/hcisync.c:3343 /v6.2-bzimage/net/bluetooth/hcisync.c:4418 /v6.2-bzimage/net/bluetooth/hcisync.c:4609 /v6.2-bzimage/net/bluetooth/hcisync.c:4689) ? pfxhcidevopensync (/v6.2-bzimage/net/bluetooth/hcisync.c:4635) ? mutexlock (/v6.2-bzimage/./arch/x86/include/asm/atomic6464.h:190 /v6.2-bzimage/./include/linux/atomic/atomic-long.h:443 /v6.2-bzimage/./include/linux/atomic/atomic-instrumented.h:1781 /v6.2-bzimage/kernel/locking/mutex.c:171 /v6.2-bzimage/kernel/locking/mutex.c:285) ? pfxmutexlock (/v6.2-bzimage/kernel/locking/mutex.c:282) hcipoweron (/v6.2-bzimage/net/bluetooth/hcicore.c:485 /v6.2-bzimage/net/bluetooth/hcicore.c:984) ? pfxhcipoweron (/v6.2-bzimage/net/bluetooth/hcicore.c:969) ? readwordatatime (/v6.2-bzimage/./include/asm-generic/rwonce.h:85) ? strscpy (/v6.2-bzimage/./arch/x86/include/asm/word-at-a-time.h:62 /v6.2-bzimage/lib/string.c:161) processonework (/v6.2-bzimage/kernel/workqueue.c:2294) workerthread (/v6.2-bzimage/./include/linux/list.h:292 /v6.2-bzimage/kernel/workqueue.c:2437) ? pfxworkerthread (/v6.2-bzimage/kernel/workqueue.c:2379) kthread (/v6.2-bzimage/kernel/kthread.c:376) ? pfxkthread (/v6.2-bzimage/kernel/kthread.c:331) retfromfork (/v6.2-bzimage/arch/x86/entry/entry64.S:314) </TASK> The buggy address belongs to the variable: ampinit1+0x30/0x60 The buggy address belongs to the physical page: page:000000003a157ec6 refcount:1 mapcount:0 mapping:0000000000000000 ia flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea0005054688 ffffea0005054688 000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffffaed1aa00: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00 ffffffffaed1aa80: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00 ffffffffaed1ab00: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 ---truncated---

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

Bluetooth: Fix race condition in hcicmdsyncclear

There is a potential race condition in hcicmdsyncwork and hcicmdsyncclear, and could lead to use-after-free. For instance, hcicmdsyncwork is added to the 'reqworkqueue' after cancelworksync The entry of 'cmdsyncworklist' may be freed in hcicmdsyncclear, and causing kernel panic when it is used in 'hcicmdsyncwork'.

Here's the call trace:

dumpstacklvl+0x49/0x63 printreport.cold+0x5e/0x5d3 ? hcicmdsyncwork+0x282/0x320 kasanreport+0xaa/0x120 ? hcicmdsyncwork+0x282/0x320 asanreportload8noabort+0x14/0x20 hcicmdsyncwork+0x282/0x320 processonework+0x77b/0x11c0 ? rawspinlockirq+0x8e/0xf0 workerthread+0x544/0x1180 ? pollidle+0x1e0/0x1e0 kthread+0x285/0x320 ? processonework+0x11c0/0x11c0 ? kthreadcompleteandexit+0x30/0x30 retfromfork+0x22/0x30 </TASK>

Allocated by task 266: kasansavestack+0x26/0x50 kasankmalloc+0xae/0xe0 kmemcachealloctrace+0x191/0x350 hcicmdsyncqueue+0x97/0x2b0 hciupdatepassivescan+0x176/0x1d0 leconncompleteevt+0x1b5/0x1a00 hcileconncompleteevt+0x234/0x340 hcilemetaevt+0x231/0x4e0 hcieventpacket+0x4c5/0xf00 hcirxwork+0x37d/0x880 processonework+0x77b/0x11c0 workerthread+0x544/0x1180 kthread+0x285/0x320 retfromfork+0x22/0x30

Freed by task 269: kasansavestack+0x26/0x50 kasansettrack+0x25/0x40 kasansetfreeinfo+0x24/0x40 kasanslabfree+0x176/0x1c0 kasanslabfree+0x12/0x20 slabfreefreelisthook+0x95/0x1a0 kfree+0xba/0x2f0 hcicmdsyncclear+0x14c/0x210 hciunregisterdev+0xff/0x440 vhcirelease+0x7b/0xf0 fput+0x1f3/0x970 fput+0xe/0x20 taskworkrun+0xd4/0x160 doexit+0x8b0/0x22a0 dogroupexit+0xba/0x2a0 getsignal+0x1e4a/0x25b0 archdosignalorrestart+0x93/0x1f80 exittousermodeprepare+0xf5/0x1a0 syscallexittousermode+0x26/0x50 retfromfork+0x15/0x30

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

KVM: Initialize gfntopfncache locks in dedicated helper

Move the gfntopfncache lock initialization to another helper and call the new helper during VM/vCPU creation. There are race conditions possible due to kvmgfntopfncacheinit()'s ability to re-initialize the cache's locks.

For example: a race between ioctl(KVMXENHVMEVTCHNSEND) and kvmgfntopfncacheinit() leads to a corrupted shinfo gpc lock.

(thread 1) | (thread 2) | kvmxensetevtchnfast | readlockirqsave(&gpc->lock, ...) | | kvmgfntopfncacheinit | rwlockinit(&gpc->lock) readunlockirqrestore(&gpc->lock, ...) |

Rename "cacheinit" and "cachedestroy" to activate+deactivate to avoid implying that the cache really is destroyed/freed.

Note, there more races in the newly named kvmgpcactivate() that will be addressed separately.

[sean: call out that this is a bug fix]

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

KVM: Reject attempts to consume or refresh inactive gfntopfncache

Reject kvmgpccheck() and kvmgpcrefresh() if the cache is inactive. Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmunotifier invalidation due to the cache not being on the list of gfns to invalidate.

Note, "active" needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmunotifier events. If a relevant mmunotifier event occurs while the cache is "active" but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmunotifier event with active users and/or kvmgpcrefresh().

A race between KVMXENATTRTYPESHAREDINFO and KVMXENHVMEVTCHNSEND can be exploited to trigger the bug.

1. Deactivate shinfo cache:

kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO kvmgpcdeactivate kvmgpcunmap gpc->valid = false gpc->khva = NULL gpc->active = false

Result: active = false, valid = false

2. Cause cache refresh:

kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast kvmgpccheck return -EWOULDBLOCK because !gpc->valid kvmxensetevtchnfast return -EWOULDBLOCK kvmgpcrefresh hvatopfnretry gpc->valid = true gpc->khva = not NULL

Result: active = false, valid = true

3. Race ioctl KVMXENHVMEVTCHNSEND against ioctl KVMXENATTRTYPESHAREDINFO:

kvmarchvmioctl case KVMXENHVMEVTCHNSEND kvmxenhvmevtchnsend kvmxensetevtchn kvmxensetevtchnfast readlock gpc->lock kvmxenhvmsetattr case KVMXENATTRTYPESHAREDINFO mutexlock kvm->lock kvmxensharedinfoinit kvmgpcactivate gpc->khva = NULL kvmgpccheck [ Check passes because gpc->valid is still true, even though gpc->khva is already NULL. ] shinfo = gpc->khva pendingbits = shinfo->evtchnpending CRASH: testandsetbit(..., pendingbits)

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

block: don't revert iter for -EIOCBQUEUED

blkdevreaditer() has a few odd checks, like gating the position and count adjustment on whether or not the result is bigger-than-or-equal to zero (where bigger than makes more sense), and not checking the return value of blkdevdirectIO() before doing an ioviterrevert(). The latter can lead to attempting to revert with a negative value, which when passed to ioviterrevert() as an unsigned value will lead to throwing a WARNON() because unroll is bigger than MAXRWCOUNT.

Be sane and don't revert for -EIOCBQUEUED, like what is done in other spots.

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

staging: media: max96712: fix kernel oops when removing module

The following kernel oops is thrown when trying to remove the max96712 module:

Unable to handle kernel paging request at virtual address 00007375746174db Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10difce polyvalce mxcjpegencdec flexcan sndsocfslsai sndsocfslasoccard sndsocfslmicfil dwcmipicsi2 imxcsiformatter polyvalgeneric v4l2jpeg imxpcmdma candev sndsocimxaudmux sndsocwm8962 sndsocimxcard sndsocfslutils max96712(C-) rpmsgctrl rpmsgchar pwmfan fuse [last unloaded: imx8isi] CPU: 0 UID: 0 PID: 754 Comm: rmmod Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ledput+0x1c/0x40 lr : v4l2subdevputprivacyled+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: ledput+0x1c/0x40 v4l2subdevputprivacyled+0x48/0x58 v4l2asyncunregistersubdev+0x2c/0x1a4 max96712remove+0x1c/0x38 [max96712] i2cdeviceremove+0x2c/0x9c deviceremove+0x4c/0x80 devicereleasedriverinternal+0x1cc/0x228 driverdetach+0x4c/0x98 busremovedriver+0x6c/0xbc driverunregister+0x30/0x60 i2cdeldriver+0x54/0x64 max96712i2cdriverexit+0x18/0x1d0 [max96712] arm64sysdeletemodule+0x1a4/0x290 invokesyscall+0x48/0x10c el0svccommon.constprop.0+0xc0/0xe0 doel0svc+0x1c/0x28 el0svc+0x34/0xd8 el0t64synchandler+0x120/0x12c el0t64sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]---

This happens because in v4l2i2csubdevinit(), the i2csetcliendata() is called again and the data is overwritten to point to sd, instead of priv. So, in remove(), the wrong pointer is passed to v4l2asyncunregistersubdev(), leading to a crash.

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

mptcp: fix race on unaccepted mptcp sockets

When the listener socket owning the relevant request is closed, it frees the unaccepted subflows and that causes later deletion of the paired MPTCP sockets.

The mptcp socket's worker can run in the time interval between such delete operations. When that happens, any access to msk->first will cause an UaF access, as the subflow cleanup did not cleared such field in the mptcp socket.

Address the issue explicitly traversing the listener socket accept queue at close time and performing the needed cleanup on the pending msk.

Note that the locking is a bit tricky, as we need to acquire the msk socket lock, while still owning the subflow socket one.

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

power: supply: core: Fix boundary conditions in interpolation

The functions powersupplytemp2resistsimple and powersupplyocv2capsimple handle boundary conditions incorrectly. The change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283 ("power: supply: core: Use library interpolation"). There are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap have the wrong order compared to temp2resist. As a consequence, ocv2cap sets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read. Second, the logic of temp2resist is also not correct. Consider the case table[] = {{20, 100}, {10, 80}, {0, 60}}. For temp=5, we expect a resistance of 70% by interpolation. However, temp2resist sets high=low=2 and returns 60.

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

x86/fpu: KVM: Set the base guest FPU uABI size to sizeof(struct kvmxsave)

Set the starting uABI size of KVM's guest FPU to 'struct kvmxsave', i.e. to KVM's historical uABI size. When saving FPU state for usersapce, KVM (well, now the FPU) sets the FP+SSE bits in the XSAVE header even if the host doesn't support XSAVE. Setting the XSAVE header allows the VM to be migrated to a host that does support XSAVE without the new host having to handle FPU state that may or may not be compatible with XSAVE.

Setting the uABI size to the host's default size results in out-of-bounds writes (setting the FP+SSE bits) and data corruption (that is thankfully caught by KASAN) when running on hosts without XSAVE, e.g. on Core2 CPUs.

WARN if the default size is larger than KVM's historical uABI size; all features that can push the FPU size beyond the historical size must be opt-in.

================================================================== BUG: KASAN: slab-out-of-bounds in fpucopyuabitoguestfpstate+0x86/0x130 Read of size 8 at addr ffff888011e33a00 by task qemu-build/681 CPU: 1 PID: 681 Comm: qemu-build Not tainted 5.18.0-rc5-KASAN-amd64 #1 Hardware name: /DG35EC, BIOS ECG3510M.86A.0118.2010.0113.1426 01/13/2010 Call Trace: <TASK> dumpstacklvl+0x34/0x45 printreport.cold+0x45/0x575 kasanreport+0x9b/0xd0 fpucopyuabitoguestfpstate+0x86/0x130 kvmarchvcpuioctl+0x72a/0x1c50 [kvm] kvmvcpuioctl+0x47f/0x7b0 [kvm] x64sysioctl+0x5de/0xc90 dosyscall64+0x31/0x50 entrySYSCALL64afterhwframe+0x44/0xae </TASK> Allocated by task 0: (stack is not available) The buggy address belongs to the object at ffff888011e33800 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 0 bytes to the right of 512-byte region [ffff888011e33800, ffff888011e33a00) The buggy address belongs to the physical page: page:0000000089cd4adb refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11e30 head:0000000089cd4adb order:2 compoundmapcount:0 compoundpincount:0 flags: 0x4000000000010200(slab|head|zone=1) raw: 4000000000010200 dead000000000100 dead000000000122 ffff888001041c80 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888011e33900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888011e33980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888011e33a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888011e33a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888011e33b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint

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

erofs: fix buffer copy overflow of ztailpacking feature

I got some KASAN report as below:

[ 46.959738] ================================================================== [ 46.960430] BUG: KASAN: use-after-free in zerofsshiftedtransform+0x2bd/0x370 [ 46.960430] Read of size 4074 at addr ffff8880300c2f8e by task fssum/188 ... [ 46.960430] Call Trace: [ 46.960430] <TASK> [ 46.960430] dumpstacklvl+0x41/0x5e [ 46.960430] printreport.cold+0xb2/0x6b7 [ 46.960430] ? zerofsshiftedtransform+0x2bd/0x370 [ 46.960430] kasanreport+0x8a/0x140 [ 46.960430] ? zerofsshiftedtransform+0x2bd/0x370 [ 46.960430] kasancheckrange+0x14d/0x1d0 [ 46.960430] memcpy+0x20/0x60 [ 46.960430] zerofsshiftedtransform+0x2bd/0x370 [ 46.960430] zerofsdecompresspcluster+0xaae/0x1080

The root cause is that the tail pcluster won't be a complete filesystem block anymore. So if ztailpacking is used, the second part of an uncompressed tail pcluster may not be rq->pageofsout.

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

bonding: fix missed rcu protection

When removing the rcureadlock in bondethtoolgettsinfo() as discussed [1], I didn't notice it could be called via setsockopt, which doesn't hold rcu lock, as syzbot pointed:

stack backtrace: CPU: 0 PID: 3599 Comm: syz-executor317 Not tainted 5.18.0-rc5-syzkaller-01392-g01f4685797a5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xcd/0x134 lib/dumpstack.c:106 bondoptionactiveslavegetrcu include/net/bonding.h:353 [inline] bondethtoolgettsinfo+0x32c/0x3a0 drivers/net/bonding/bondmain.c:5595 ethtoolgettsinfo+0x173/0x240 net/ethtool/common.c:554 ethtoolgetphcvclocks+0x99/0x110 net/ethtool/common.c:568 socktimestampingbindphc net/core/sock.c:869 [inline] socksettimestamping+0x3a3/0x7e0 net/core/sock.c:916 socksetsockopt+0x543/0x2ec0 net/core/sock.c:1221 syssetsockopt+0x55e/0x6a0 net/socket.c:2223 dosyssetsockopt net/socket.c:2238 [inline] sesyssetsockopt net/socket.c:2235 [inline] x64syssetsockopt+0xba/0x150 net/socket.c:2235 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f8902c8eb39

Fix it by adding rcureadlock and take a ref on the realdev. Since devhold() and devput() can take NULL these days, we can skip checking if realdev exist.

[1] https://lore.kernel.org/netdev/27565.1642742439@famine/