exit: prevent preemption of oopsing TASKDEAD task
fscache: delete fscachecookielrutimer when fscache exits to avoid UAF
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.
A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat.
A flaw in the Linux Kernel found. If unprivileged users can mount FUSE filesystems, then can trigger use after free (UAF) that reads of write() buffers, allowing theft of (partial) /etc/shadow hashes or any other data from filesystem.
FUSE allows the userspace filesystem to specify on FUSEOPEN whether the file should use the normal kernel pagecache for handling read()/write() or just send FUSEREAD/FUSEWRITE requests directly to the userspace filesystem (using the flag FOPENDIRECTIO in fuseopenout::openflags).
In FOPENDIRECTIO mode, fusefilewriteiter() calls fusedirectwriteiter(), which normally calls fusedirectio(), which then imports the write buffer with fusegetuserpages(), which uses iovitergetpages() to grab references to userspace pages instead of actually copying memory.
On the filesystem device side, these pages can then either be read to userspace (via fusedevread()), or splice()d over into a pipe using fusedevspliceread() as pipe buffers with &nostealpipebufops.
This is wrong because after fusedevdoread() unlocks the FUSE request, the userspace filesystem can mark the request as completed, causing write() to return. At that point, the write buffer may be reused for other purposes, and the userspace filesystem should no longer have access to it.
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system.
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 before 5.17.3, fs/iouring.c has a use-after-free due to a race condition in iouring timeouts. This can be triggered by a local user who has no access to any user namespace; however, the race condition perhaps can only be exploited infrequently.
A use-after-free exists in the Linux Kernel in tcnewtfilter that could allow a local attacker to gain privilege escalation. The exploit requires unprivileged user namespaces. We recommend upgrading past commit 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5
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:
bfq: fix use-after-free in bfqdispatchrequest
KASAN reports a use-after-free report when doing normal scsi-mq test
[69832.239032] ================================================================== [69832.241810] BUG: KASAN: use-after-free in bfqdispatchrequest+0x1045/0x44b0 [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155 [69832.244656] [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8 [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [69832.249069] Workqueue: kblockd blkmqrunworkfn [69832.250022] Call Trace: [69832.250541] dumpstack+0x9b/0xce [69832.251232] ? bfqdispatchrequest+0x1045/0x44b0 [69832.252243] printaddressdescription.constprop.6+0x3e/0x60 [69832.253381] ? cpuidletextend+0x5/0x5 [69832.254211] ? vprintkfunc+0x6b/0x120 [69832.254994] ? bfqdispatchrequest+0x1045/0x44b0 [69832.255952] ? bfqdispatchrequest+0x1045/0x44b0 [69832.256914] kasanreport.cold.9+0x22/0x3a [69832.257753] ? bfqdispatchrequest+0x1045/0x44b0 [69832.258755] checkmemoryregion+0x1c1/0x1e0 [69832.260248] bfqdispatchrequest+0x1045/0x44b0 [69832.261181] ? bfqbfqqexpire+0x2440/0x2440 [69832.262032] ? blkmqdelayrunhwqueues+0xf9/0x170 [69832.263022] blkmqdodispatchsched+0x52f/0x830 [69832.264011] ? blkmqschedrequestinserted+0x100/0x100 [69832.265101] blkmqscheddispatchrequests+0x398/0x4f0 [69832.266206] ? blkmqdodispatchctx+0x570/0x570 [69832.267147] ? switchto+0x5f4/0xee0 [69832.267898] blkmqscheddispatchrequests+0xdf/0x140 [69832.268946] blkmqrunhwqueue+0xc0/0x270 [69832.269840] blkmqrunworkfn+0x51/0x60 [69832.278170] processonework+0x6d4/0xfe0 [69832.278984] workerthread+0x91/0xc80 [69832.279726] ? kthreadparkme+0xb0/0x110 [69832.280554] ? processonework+0xfe0/0xfe0 [69832.281414] kthread+0x32d/0x3f0 [69832.282082] ? kthreadpark+0x170/0x170 [69832.282849] retfromfork+0x1f/0x30 [69832.283573] [69832.283886] Allocated by task 7725: [69832.284599] kasansavestack+0x19/0x40 [69832.285385] kasankmalloc.constprop.2+0xc1/0xd0 [69832.286350] kmemcacheallocnode+0x13f/0x460 [69832.287237] bfqgetqueue+0x3d4/0x1140 [69832.287993] bfqgetbfqqhandlesplit+0x103/0x510 [69832.289015] bfqinitrq+0x337/0x2d50 [69832.289749] bfqinsertrequests+0x304/0x4e10 [69832.290634] blkmqschedinsertrequests+0x13e/0x390 [69832.291629] blkmqflushpluglist+0x4b4/0x760 [69832.292538] blkflushpluglist+0x2c5/0x480 [69832.293392] ioscheduleprepare+0xb2/0xd0 [69832.294209] ioscheduletimeout+0x13/0x80 [69832.295014] waitforcommonio.constprop.1+0x13c/0x270 [69832.296137] submitbiowait+0x103/0x1a0 [69832.296932] blkdevissuediscard+0xe6/0x160 [69832.297794] blkioctldiscard+0x219/0x290 [69832.298614] blkdevcommonioctl+0x50a/0x1750 [69832.304715] blkdevioctl+0x470/0x600 [69832.305474] blockioctl+0xde/0x120 [69832.306232] vfsioctl+0x6c/0xc0 [69832.306877] sesysioctl+0x90/0xa0 [69832.307629] dosyscall64+0x2d/0x40 [69832.308362] entrySYSCALL64afterhwframe+0x44/0xa9 [69832.309382] [69832.309701] Freed by task 155: [69832.310328] kasansavestack+0x19/0x40 [69832.311121] kasansettrack+0x1c/0x30 [69832.311868] kasansetfreeinfo+0x1b/0x30 [69832.312699] kasanslabfree+0x111/0x160 [69832.313524] kmemcachefree+0x94/0x460 [69832.314367] bfqputqueue+0x582/0x940 [69832.315112] bfqbfqdresetinservice+0x166/0x1d0 [69832.317275] bfqbfqqexpire+0xb27/0x2440 [69832.318084] bfqdispatchrequest+0x697/0x44b0 [69832.318991] blkmqdodispatchsched+0x52f/0x830 [69832.319984] blkmqscheddispatchrequests+0x398/0x4f0 [69832.321087] blkmqscheddispatchrequests+0xdf/0x140 [69832.322225] blkmqrunhwqueue+0xc0/0x270 [69832.323114] blkmqrunworkfn+0x51/0x6 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on curseg->alloctype
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/showbug.cgi?id=215657
- Overview UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 when mount and operate a corrupted image
- Reproduce tested on kernel 5.17-rc4, 5.17-rc6
1. mkdir testcrash 2. cd testcrash 3. unzip tmp2.zip 4. mkdir mnt 5. ./singletest.sh f2fs 2
- Kernel dump [ 46.434454] loop0: detected capacity change from 0 to 131072 [ 46.529839] F2FS-fs (loop0): Mounted with checkpoint version = 7548c2d9 [ 46.738319] ================================================================================ [ 46.738412] UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 [ 46.738475] index 231 is out of range for type 'unsigned int [2]' [ 46.738539] CPU: 2 PID: 939 Comm: umount Not tainted 5.17.0-rc6 #1 [ 46.738547] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 46.738551] Call Trace: [ 46.738556] <TASK> [ 46.738563] dumpstacklvl+0x47/0x5c [ 46.738581] ubsanepilogue+0x5/0x50 [ 46.738592] ubsanhandleoutofbounds+0x68/0x80 [ 46.738604] f2fsallocatedatablock+0xdff/0xe60 [f2fs] [ 46.738819] dowritepage+0xef/0x210 [f2fs] [ 46.738934] f2fsdowritenodepage+0x3f/0x80 [f2fs] [ 46.739038] writenodepage+0x2b7/0x920 [f2fs] [ 46.739162] f2fssyncnodepages+0x943/0xb00 [f2fs] [ 46.739293] f2fswritecheckpoint+0x7bb/0x1030 [f2fs] [ 46.739405] killf2fssuper+0x125/0x150 [f2fs] [ 46.739507] deactivatelockedsuper+0x60/0xc0 [ 46.739517] deactivatesuper+0x70/0xb0 [ 46.739524] cleanupmnt+0x11a/0x200 [ 46.739532] cleanupmnt+0x16/0x20 [ 46.739538] taskworkrun+0x67/0xa0 [ 46.739547] exittousermodeprepare+0x18c/0x1a0 [ 46.739559] syscallexittousermode+0x26/0x40 [ 46.739568] dosyscall64+0x46/0xb0 [ 46.739584] entrySYSCALL64afterhwframe+0x44/0xae
The root cause is we missed to do sanity check on curseg->alloctype, result in out-of-bound accessing on sbi->blockcount[] array, fix it.
In the Linux kernel, the following vulnerability has been resolved:
block, bfq: don't move oombfqq
Our test report a UAF:
[ 2073.019181] ================================================================== [ 2073.019188] BUG: KASAN: use-after-free in bfqputasyncbfqq+0xa0/0x168 [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584 [ 2073.019192] [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5 [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 2073.019200] Call trace: [ 2073.019203] dumpbacktrace+0x0/0x310 [ 2073.019206] showstack+0x28/0x38 [ 2073.019210] dumpstack+0xec/0x15c [ 2073.019216] printaddressdescription+0x68/0x2d0 [ 2073.019220] kasanreport+0x238/0x2f0 [ 2073.019224] asanstore8+0x88/0xb0 [ 2073.019229] bfqputasyncbfqq+0xa0/0x168 [ 2073.019233] bfqputasyncqueues+0xbc/0x208 [ 2073.019236] bfqpdoffline+0x178/0x238 [ 2073.019240] blkcgdeactivatepolicy+0x1f0/0x420 [ 2073.019244] bfqexitqueue+0x128/0x178 [ 2073.019249] blkmqexitsched+0x12c/0x160 [ 2073.019252] elevatorexit+0xc8/0xd0 [ 2073.019256] blkexitqueue+0x50/0x88 [ 2073.019259] blkcleanupqueue+0x228/0x3d8 [ 2073.019267] nulldeldev+0xfc/0x1e0 [nullblk] [ 2073.019274] nullexit+0x90/0x114 [nullblk] [ 2073.019278] arm64sysdeletemodule+0x358/0x5a0 [ 2073.019282] el0svccommon+0xc8/0x320 [ 2073.019287] el0svchandler+0xf8/0x160 [ 2073.019290] el0svc+0x10/0x218 [ 2073.019291] [ 2073.019294] Allocated by task 14163: [ 2073.019301] kasankmalloc+0xe0/0x190 [ 2073.019305] kmemcacheallocnodetrace+0x1cc/0x418 [ 2073.019308] bfqpdalloc+0x54/0x118 [ 2073.019313] blkcgactivatepolicy+0x250/0x460 [ 2073.019317] bfqcreategrouphierarchy+0x38/0x110 [ 2073.019321] bfqinitqueue+0x6d0/0x948 [ 2073.019325] blkmqinitsched+0x1d8/0x390 [ 2073.019330] elevatorswitchmq+0x88/0x170 [ 2073.019334] elevatorswitch+0x140/0x270 [ 2073.019338] elvioschedstore+0x1a4/0x2a0 [ 2073.019342] queueattrstore+0x90/0xe0 [ 2073.019348] sysfskfwrite+0xa8/0xe8 [ 2073.019351] kernfsfopwrite+0x1f8/0x378 [ 2073.019359] vfswrite+0xe0/0x360 [ 2073.019363] vfswrite+0xf0/0x270 [ 2073.019367] ksyswrite+0xdc/0x1b8 [ 2073.019371] arm64syswrite+0x50/0x60 [ 2073.019375] el0svccommon+0xc8/0x320 [ 2073.019380] el0svchandler+0xf8/0x160 [ 2073.019383] el0svc+0x10/0x218 [ 2073.019385] [ 2073.019387] Freed by task 72584: [ 2073.019391] kasanslabfree+0x120/0x228 [ 2073.019394] kasanslabfree+0x10/0x18 [ 2073.019397] kfree+0x94/0x368 [ 2073.019400] bfqgput+0x64/0xb0 [ 2073.019404] bfqgandblkgput+0x90/0xb0 [ 2073.019408] bfqputqueue+0x220/0x228 [ 2073.019413] bfqputasyncbfqq+0x98/0x168 [ 2073.019416] bfqputasyncqueues+0xbc/0x208 [ 2073.019420] bfqpdoffline+0x178/0x238 [ 2073.019424] blkcgdeactivatepolicy+0x1f0/0x420 [ 2073.019429] bfqexitqueue+0x128/0x178 [ 2073.019433] blkmqexitsched+0x12c/0x160 [ 2073.019437] elevatorexit+0xc8/0xd0 [ 2073.019440] blkexitqueue+0x50/0x88 [ 2073.019443] blkcleanupqueue+0x228/0x3d8 [ 2073.019451] nulldeldev+0xfc/0x1e0 [nullblk] [ 2073.019459] nullexit+0x90/0x114 [nullblk] [ 2073.019462] arm64sysdeletemodule+0x358/0x5a0 [ 2073.019467] el0svccommon+0xc8/0x320 [ 2073.019471] el0svchandler+0xf8/0x160 [ 2073.019474] el0svc+0x10/0x218 [ 2073.019475] [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00 which belongs to the cache kmalloc-1024 of size 1024 [ 2073.019484] The buggy address is located 552 bytes inside of 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300) [ 2073.019486] The buggy address belongs to the page: [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compoundmapcount: 0 [ 2073.020123] flags: 0x7ffff0000008100(slab|head) [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00 [ 2073.020409] ra ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Implement ref count for SRB
The timeout handler and the done function are racing. When qla2x00asynciocbtimeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xxasyncgpscspdone() releases the SRB unconditionally. When scheduling back to qla2x00asynciocbtimeout() qla24xxasyncabortcmd() will access an freed sp->qpair pointer:
qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xxhandlegpscevent 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xxasyncabortcmd+0x1b/0x1c0 [qla2xxx]
Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.
When we are able to cancel a timer (deltimer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.
If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling krefput().
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7921: fix crash when startup fails.
If the nic fails to start, it is possible that the resetwork has already been scheduled. Ensure the work item is canceled so we do not have use-after-free crash in case cleanup is called before the work item is executed.
This fixes crash on my x8664 apu2 when mt7921k radio fails to work. Radio still fails, but OS does not crash.
In the Linux kernel, the following vulnerability has been resolved:
Revert "Revert "block, bfq: honor already-setup queue merges""
A crash [1] happened to be triggered in conjunction with commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq: honor already-setup queue merges""). Yet, the reverted commit was not the one introducing the bug. In fact, it actually triggered a UAF introduced by a different commit, and now fixed by commit d29bd41428cf ("block, bfq: reset lastbfqqcreated on group change").
So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges") out. This commit restores it.
[1] https://bugzilla.kernel.org/showbug.cgi?id=214503
ax25: Fix netdev refcount issue
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.
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:
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:
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.
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.
Bluetooth: MGMT: Fix slab-use-after-free Read in setpoweredsync
In the Linux kernel, the following vulnerability has been resolved:
block, bfq: fix bfqq uaf in bfqlimitdepth()
Set new allocated bfqq to bic or remove freed bfqq from bic are both protected by bfqd->lock, however bfqlimitdepth() is deferencing bfqq from bic without the lock, this can lead to UAF if the iocontext is shared by multiple tasks.
For example, test bfq with iouring can trigger following UAF in v6.6:
================================================================== BUG: KASAN: slab-use-after-free in bfqqgroup+0x15/0x50
Call Trace: <TASK> dumpstacklvl+0x47/0x80 printaddressdescription.constprop.0+0x66/0x300 printreport+0x3e/0x70 kasanreport+0xb4/0xf0 bfqqgroup+0x15/0x50 bfqqrequestoverlimit+0x130/0x9a0 bfqlimitdepth+0x1b5/0x480 blkmqallocrequests+0x2b5/0xa00 blkmqgetnewrequests+0x11d/0x1d0 blkmqsubmitbio+0x286/0xb00 submitbionoacctnocheck+0x331/0x400 blockwritefullfolio+0x3d0/0x640 writepagecb+0x3b/0xc0 writecachepages+0x254/0x6c0 writecachepages+0x254/0x6c0 dowritepages+0x192/0x310 filemapfdatawritewbc+0x95/0xc0 filemapfdatawriterange+0x99/0xd0 filemapwriteandwaitrange.part.0+0x4d/0xa0 blkdevreaditer+0xef/0x1e0 ioread+0x1b6/0x8a0 ioissuesqe+0x87/0x300 iowqsubmitwork+0xeb/0x390 ioworkerhandlework+0x24d/0x550 iowqworker+0x27f/0x6c0 retfromforkasm+0x1b/0x30 </TASK>
Allocated by task 808602: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasanslaballoc+0x83/0x90 kmemcacheallocnode+0x1b1/0x6d0 bfqgetqueue+0x138/0xfa0 bfqgetbfqqhandlesplit+0xe3/0x2c0 bfqinitrq+0x196/0xbb0 bfqinsertrequest.isra.0+0xb5/0x480 bfqinsertrequests+0x156/0x180 blkmqinsertrequest+0x15d/0x440 blkmqsubmitbio+0x8a4/0xb00 submitbionoacctnocheck+0x331/0x400 blkdevdirectIOasync+0x2dd/0x330 blkdevwriteiter+0x39a/0x450 iowrite+0x22a/0x840 ioissuesqe+0x87/0x300 iowqsubmitwork+0xeb/0x390 ioworkerhandlework+0x24d/0x550 iowqworker+0x27f/0x6c0 retfromfork+0x2d/0x50 retfromforkasm+0x1b/0x30
Freed by task 808589: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansavefreeinfo+0x27/0x40 kasanslabfree+0x126/0x1b0 kmemcachefree+0x10c/0x750 bfqputqueue+0x2dd/0x770 bfqinsertrequest.isra.0+0x155/0x7a0 bfqinsertrequest.isra.0+0x122/0x480 bfqinsertrequests+0x156/0x180 blkmqdispatchpluglist+0x528/0x7e0 blkmqflushpluglist.part.0+0xe5/0x590 blkflushplug+0x3b/0x90 blkfinishplug+0x40/0x60 dowritepages+0x19d/0x310 filemapfdatawritewbc+0x95/0xc0 filemapfdatawriterange+0x99/0xd0 filemapwriteandwaitrange.part.0+0x4d/0xa0 blkdevreaditer+0xef/0x1e0 ioread+0x1b6/0x8a0 ioissuesqe+0x87/0x300 iowqsubmitwork+0xeb/0x390 ioworkerhandlework+0x24d/0x550 iowqworker+0x27f/0x6c0 retfromfork+0x2d/0x50 retfromforkasm+0x1b/0x30
Fix the problem by protecting bictobfqq() with bfqd->lock.
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: x86-android-tablets: Fix use after free on platformdeviceregister() errors
x86androidtabletremove() frees the pdevs[] array, so it should not be used after calling x86androidtabletremove().
When platformdeviceregister() fails, store the pdevs[x] PTRERR() value into the local ret variable before calling x86androidtabletremove() to avoid using pdevs[] after it has been freed.
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire kvm->srcu when handling KVMSETVCPUEVENTS
Grab kvm->srcu when processing KVMSETVCPUEVENTS, as KVM will forcibly leave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX reads guest memory.
Note, kvmvcpuioctlx86setvcpuevents() can also be called from KVMRUN via syncregs(), which already holds SRCU. I.e. trying to precisely use kvmvcpusrcureadlock() around the problematic SMM code would cause problems. Acquiring SRCU isn't all that expensive, so for simplicity, grab it unconditionally for KVMSETVCPUEVENTS.
============================= WARNING: suspicious RCU usage 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted ----------------------------- include/linux/kvmhost.h:1027 suspicious rcudereferencecheck() usage!
other info that might help us debug this:
rcuscheduleractive = 2, debuglocks = 1 1 lock held by repro/1071: #0: ffff88811e424430 (&vcpu->mutex){+.+.}-{3:3}, at: kvmvcpuioctl+0x7d/0x970 [kvm]
stack backtrace: CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x7f/0x90 lockdeprcususpicious+0x13f/0x1a0 kvmvcpugfntomemslot+0x168/0x190 [kvm] kvmvcpureadguest+0x3e/0x90 [kvm] nestedvmxloadmsr+0x6b/0x1d0 [kvmintel] loadvmcs12hoststate+0x432/0xb40 [kvmintel] vmxleavenested+0x30/0x40 [kvmintel] kvmvcpuioctlx86setvcpuevents+0x15d/0x2b0 [kvm] kvmarchvcpuioctl+0x1107/0x1750 [kvm] ? markheldlocks+0x49/0x70 ? kvmvcpuioctl+0x7d/0x970 [kvm] ? kvmvcpuioctl+0x497/0x970 [kvm] kvmvcpuioctl+0x497/0x970 [kvm] ? lockacquire+0xba/0x2d0 ? findheldlock+0x2b/0x80 ? douseraddrfault+0x40c/0x6f0 ? lockrelease+0xb7/0x270 x64sysioctl+0x82/0xb0 dosyscall64+0x6c/0x170 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7ff11eb1b539 </TASK>
binder: fix UAF caused by offsets overwrite
In the Linux kernel, the following vulnerability has been resolved:
fs/netfs/fscachecookie: add missing "naccesses" check
This fixes a NULL pointer dereference bug due to a data race which looks like this:
BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 33 PID: 16573 Comm: kworker/u97:799 Not tainted 6.8.7-cm4all1-hp+ #43 Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 10/17/2018 Workqueue: eventsunbound netfsrreqwritetocachework RIP: 0010:cachefilespreparewrite+0x30/0xa0 Code: 57 41 56 45 89 ce 41 55 49 89 cd 41 54 49 89 d4 55 53 48 89 fb 48 83 ec 08 48 8b 47 08 48 83 7f 10 00 48 89 34 24 48 8b 68 20 <48> 8b 45 08 4c 8b 38 74 45 49 8b 7f 50 e8 4e a9 b0 ff 48 8b 73 10 RSP: 0018:ffffb4e78113bde0 EFLAGS: 00010286 RAX: ffff976126be6d10 RBX: ffff97615cdb8438 RCX: 0000000000020000 RDX: ffff97605e6c4c68 RSI: ffff97605e6c4c60 RDI: ffff97615cdb8438 RBP: 0000000000000000 R08: 0000000000278333 R09: 0000000000000001 R10: ffff97605e6c4600 R11: 0000000000000001 R12: ffff97605e6c4c68 R13: 0000000000020000 R14: 0000000000000001 R15: ffff976064fe2c00 FS: 0000000000000000(0000) GS:ffff9776dfd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000005942c002 CR4: 00000000001706f0 Call Trace: <TASK> ? die+0x1f/0x70 ? pagefaultoops+0x15d/0x440 ? searchmoduleextables+0xe/0x40 ? fixupexception+0x22/0x2f0 ? excpagefault+0x5f/0x100 ? asmexcpagefault+0x22/0x30 ? cachefilespreparewrite+0x30/0xa0 netfsrreqwritetocachework+0x135/0x2e0 processonework+0x137/0x2c0 workerthread+0x2e9/0x400 ? pfxworkerthread+0x10/0x10 kthread+0xcc/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x30/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK> Modules linked in: CR2: 0000000000000008 ---[ end trace 0000000000000000 ]---
This happened because fscachecookiestatemachine() was slow and was still running while another process invoked fscacheunusecookie(); this led to a fscachecookielrudoone() call, setting the FSCACHECOOKIEDOLRUDISCARD flag, which was picked up by fscachecookiestatemachine(), withdrawing the cookie via cachefileswithdrawcookie(), clearing cookie->cachepriv.
At the same time, yet another process invoked cachefilespreparewrite(), which found a NULL pointer in this code line:
struct cachefilesobject object = cachefilescresobject(cres);
The next line crashes, obviously:
struct cachefilescache cache = object->volume->cache;
During cachefilespreparewrite(), the "naccesses" counter is non-zero (via fscachebeginoperation()). The cookie must not be withdrawn until it drops to zero.
The counter is checked by fscachecookiestatemachine() before switching to FSCACHECOOKIESTATERELINQUISHING and FSCACHECOOKIESTATEWITHDRAWING (in "case FSCACHECOOKIESTATEFAILED"), but not for FSCACHECOOKIESTATELRUDISCARDING ("case FSCACHECOOKIESTATEACTIVE").
This patch adds the missing check. With a non-zero access counter, the function returns and the next fscacheendcookieaccess() call will queue another fscachecookiestatemachine() call to handle the still-pending FSCACHECOOKIEDOLRUDISCARD.