In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in SMB request handling
A race condition exists between SMB request handling in ksmbdconnhandlerloop() and the freeing of ksmbdconn in the workqueue handler handleksmbdwork(). This leads to a UAF. - KASAN: slab-use-after-free Read in handleksmbdwork - KASAN: slab-use-after-free in rtlockslowlocklocked
This race condition arises as follows: - ksmbdconnhandlerloop() waits for conn->rcount to reach zero: waitevent(conn->rcountq, atomicread(&conn->rcount) == 0); - Meanwhile, handleksmbdwork() decrements conn->rcount using atomicdecreturn(&conn->rcount), and if it reaches zero, calls ksmbdconnfree(), which frees conn. - However, after handleksmbdwork() decrements conn->rcount, it may still access conn->rcountq in the following line: waitqueueactive(&conn->rcountq) or wakeup(&conn->rcountq) This results in a UAF, as conn has already been freed.
The discovery of this UAF can be referenced in the following PR for syzkaller's support for SMB requests.
In the Linux kernel, the following vulnerability has been resolved:
smb: prevent use-after-free due to opencacheddir error paths
If opencacheddir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in opencacheddir() freeing the cfid while the queued work is pending.
Update opencacheddir() to drop refs rather than directly freeing the cfid.
Have cacheddirleasebreak(), cfidslaundromatworker(), and invalidateallcacheddirs() clear haslease immediately while still holding cfids->cfidlistlock, and then use this to also simplify the reference counting in cfidslaundromatworker() and invalidateallcacheddirs().
Fixes this KASAN splat (which manually injects an error and lease break in opencacheddir()):
================================================================== BUG: KASAN: slab-use-after-free in smb2cachedleasebreak+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65
CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2cachedleasebreak Call Trace: <TASK> dumpstacklvl+0x77/0xb0 printreport+0xce/0x660 kasanreport+0xd3/0x110 smb2cachedleasebreak+0x27/0xb0 processonework+0x50a/0xc50 workerthread+0x2ba/0x530 kthread+0x17c/0x1c0 retfromfork+0x34/0x60 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 2464: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasankmalloc+0xaa/0xb0 opencacheddir+0xa7d/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64afterhwframe+0x76/0x7e
Freed by task 2464: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x51/0x70 kfree+0x174/0x520 opencacheddir+0x97f/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64afterhwframe+0x76/0x7e
Last potentially related work creation: kasansavestack+0x33/0x60 kasanrecordauxstack+0xad/0xc0 insertwork+0x32/0x100 queuework+0x5c9/0x870 queueworkon+0x82/0x90 opencacheddir+0x1369/0x1fb0 smb2querypathinfo+0x43c/0x6e0 cifsgetfattr+0x346/0xf10 cifsgetinodeinfo+0x157/0x210 cifsrevalidatedentryattr+0x2d1/0x460 cifsgetattr+0x173/0x470 vfsstatxpath+0x10f/0x160 vfsstatx+0xe9/0x150 vfsfstatat+0x5e/0xc0 dosysnewfstatat+0x91/0xf0 dosyscall64+0x95/0x1a0 entrySYSCALL64afterhwframe+0x76/0x7e
The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)
In the Linux kernel, the following vulnerability has been resolved:
smb: During unmount, ensure all cached dir instances drop their dentry
The unmount process (cifskillsb() calling closeallcacheddirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs:
BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661!
This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including:
- Receiving a lease break from the server - Server reconnection triggers invalidateallcacheddirs(), which removes all the cfids from the list - The laundromat thread decides to expire an old cfid.
To solve these problems, dropping the dentry is done in queued work done in a newly-added cfidputwq workqueue, and closeallcacheddirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal.
The final cleanup work for cleaning up a cfid is performed via work queued in the serverclosewq workqueue; this is done separate from dropping the dentries so that closeallcacheddirs() doesn't block on any server operations.
Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing.
While we're here, add proper locking to closeallcacheddirs(), and locking around the freeing of cfid->dentry.
In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix use-after-free of nreq in reqsktimerhandler().
The cited commit replaced inetcskreqskqueuedropandput() with inetcskreqskqueuedrop() and reqskput() in reqsktimerhandler().
Then, oreq should be passed to reqskput() instead of req; otherwise use-after-free of nreq could happen when reqsk is migrated but the retry attempt failed (e.g. due to timeout).
Let's pass oreq to reqskput().
In the Linux kernel, the following vulnerability has been resolved:
nvme-fabrics: fix kernel crash while shutting down controller
The nvme keep-alive operation, which executes at a periodic interval, could potentially sneak in while shutting down a fabric controller. This may lead to a race between the fabric controller admin queue destroy code path (invoked while shutting down controller) and hw/hctx queue dispatcher called from the nvme keep-alive async request queuing operation. This race could lead to the kernel crash shown below:
Call Trace: autoremovewakefunction+0x0/0xbc (unreliable) blkmqscheddispatchrequests+0x114/0x24c blkmqscheddispatchrequests+0x44/0x84 blkmqrunhwqueue+0x140/0x220 nvmekeepalivework+0xc8/0x19c [nvmecore] processonework+0x200/0x4e0 workerthread+0x340/0x504 kthread+0x138/0x140 startkernelthread+0x14/0x18
While shutting down fabric controller, if nvme keep-alive request sneaks in then it would be flushed off. The nvmekeepaliveendio function is then invoked to handle the end of the keep-alive operation which decrements the admin->qusagecounter and assuming this is the last/only request in the admin queue then the admin->qusagecounter becomes zero. If that happens then blk-mq destroy queue operation (blkmqdestroy queue()) which could be potentially running simultaneously on another cpu (as this is the controller shutdown code path) would forward progress and deletes the admin queue. So, now from this point onward we are not supposed to access the admin queue resources. However the issue here's that the nvme keep-alive thread running hw/hctx queue dispatch operation hasn't yet finished its work and so it could still potentially access the admin queue resource while the admin queue had been already deleted and that causes the above crash.
The above kernel crash is regression caused due to changes implemented in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()"). Ideally we should stop keep-alive before destroyin g the admin queue and freeing the admin tagset so that it wouldn't sneak in during the shutdown operation. However we removed the keep alive stop operation from the beginning of the controller shutdown code path in commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()") and added it under nvmeuninitctrl() which executes very late in the shutdown code path after the admin queue is destroyed and its tagset is removed. So this change created the possibility of keep-alive sneaking in and interfering with the shutdown operation and causing observed kernel crash.
To fix the observed crash, we decided to move nvmestopkeepalive() from nvmeuninitctrl() to nvmeremoveadmintagset(). This change would ensure that we don't forward progress and delete the admin queue until the keep- alive operation is finished (if it's in-flight) or cancelled and that would help contain the race condition explained above and hence avoid the crash.
Moving nvmestopkeepalive() to nvmeremoveadmintagset() instead of adding nvmestopkeepalive() to the beginning of the controller shutdown code path in nvmestopctrl(), as was the case earlier before commit a54a93d0e359 ("nvme: move stopping keep-alive into nvmeuninitctrl()"), would help save one callsite of nvmestopkeepalive().
In the Linux kernel, the following vulnerability has been resolved:
bnxten: Fix receive ring space parameters when XDP is active
The MTU setting at the time an XDP multi-buffer is attached determines whether the aggregation ring will be used and the rxskbfunc handler. This is done in bnxtsetrxskbmode().
If the MTU is later changed, the aggregation ring setting may need to be changed and it may become out-of-sync with the settings initially done in bnxtsetrxskbmode(). This may result in random memory corruption and crashes as the HW may DMA data larger than the allocated buffer size, such as:
BUG: kernel NULL pointer dereference, address: 00000000000003c0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S OE 6.1.0-226bf9805506 #1 Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E3A12 08/26/2021 RIP: 0010:bnxtrxpkt+0xe97/0x1ae0 [bnxten] Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 <0f> b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f RSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202 RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff RDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380 RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf R10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980 R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990 FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> bnxtpollwork+0x1c2/0x3e0 [bnxten]
To address the issue, we now call bnxtsetrxskbmode() within bnxtchangemtu() to properly set the AGG rings configuration and update rxskbfunc based on the new MTU value. Additionally, BNXTFLAGNOAGGRINGS is cleared at the beginning of bnxtsetrxskbmode() to make sure it gets set or cleared based on the current MTU.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxtre: Fix max SGEs for the Work Request
Gen P7 supports up to 13 SGEs for now. WQE software structure can hold only 6 now. Since the max send sge is reported as 13, the stack can give requests up to 13 SGEs. This is causing traffic failures and system crashes.
Use the define for max SGE supported for variable size. This will work for both static and variable WQEs.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs: Add missing deinit() call
A warning is triggered when repeatedly connecting and disconnecting the rnbd: listadd corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340). WARNING: CPU: 1 PID: 36562 at lib/listdebug.c:32 listaddvalidorreport+0x7f/0xa0 Workqueue: ibcm cmworkhandler [ibcm] RIP: 0010:listaddvalidorreport+0x7f/0xa0 ? listaddvalidorreport+0x7f/0xa0 ibregistereventhandler+0x65/0x93 [ibcore] rtrssrvibdevinit+0x29/0x30 [rtrsserver] rtrsibdevfindoradd+0x124/0x1d0 [rtrscore] allocpath+0x46c/0x680 [rtrsserver] ? rtrsrdmaconnect+0xa6/0x2d0 [rtrsserver] ? rcuiswatching+0xd/0x40 ? mutexlock+0x312/0xcf0 ? getorcreatesrv+0xad/0x310 [rtrsserver] ? rtrsrdmaconnect+0xa6/0x2d0 [rtrsserver] rtrsrdmaconnect+0x23c/0x2d0 [rtrsserver] ? lockrelease+0x1b1/0x2d0 cmacmeventhandler+0x4a/0x1a0 [rdmacm] cmaibreqhandler+0x3a0/0x7e0 [rdmacm] cmprocesswork+0x28/0x1a0 [ibcm] ? rawspinunlockirq+0x2f/0x50 cmreqhandler+0x618/0xa60 [ibcm] cmworkhandler+0x71/0x520 [ibcm]
Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a new element .deinit but never used it at all. Fix it by invoking the deinit() to appropriately unregister the IB event handler.
In the Linux kernel, the following vulnerability has been resolved:
netmem: prevent TX of unreadable skbs
Currently on stable trees we have support for netmem/devmem RX but not TX. It is not safe to forward/redirect an RX unreadable netmem packet into the device's TX path, as the device may call dma-mapping APIs on dma addrs that should not be passed to it.
Fix this by preventing the xmit of unreadable skbs.
Tested by configuring tc redirect:
sudo tc qdisc add dev eth1 ingress sudo tc filter add dev eth1 ingress protocol ip prio 1 flower ipproto \ tcp srcip 192.168.1.12 action mirred egress redirect dev eth1
Before, I see unreadable skbs in the driver's TX path passed to dma mapping APIs.
After, I don't see unreadable skbs in the driver's TX path passed to dma mapping APIs.
In the Linux kernel, the following vulnerability has been resolved:
fs/netfs/readcollect: add to next->prevdonated
If multiple subrequests donate data to the same "next" request (depending on the subrequest completion order), each of them would overwrite the prevdonated field, causing data corruption and a BUG() crash ("Can't donate prior to front").
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix oops in write-retry from mis-resetting the subreq iterator
Fix the resetting of the subrequest iterator in netfsretrywritestream() to use the iterator-reset function as the iterator may have been shortened by a previous retry. In such a case, the amount of data to be written by the subrequest is not "subreq->len" but "subreq->len - subreq->transferred".
Without this, KASAN may see an error in ioviterrevert():
BUG: KASAN: slab-out-of-bounds in ioviterrevert lib/ioviter.c:633 [inline] BUG: KASAN: slab-out-of-bounds in ioviterrevert+0x443/0x5a0 lib/ioviter.c:611 Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147
CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: eventsunbound netfswritecollectionworker Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 ioviterrevert lib/ioviter.c:633 [inline] ioviterrevert+0x443/0x5a0 lib/ioviter.c:611 netfsretrywritestream fs/netfs/writeretry.c:44 [inline] netfsretrywrites+0x166d/0x1a50 fs/netfs/writeretry.c:231 netfscollectwriteresults fs/netfs/writecollect.c:352 [inline] netfswritecollectionworker+0x23fd/0x3830 fs/netfs/writecollect.c:374 processonework+0x9cf/0x1b70 kernel/workqueue.c:3238 processscheduledworks kernel/workqueue.c:3319 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 retfromfork+0x45/0x80 arch/x86/kernel/process.c:153 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix oops due to uninitialised variable
Fix smb3inittransformrq() to initialise buffer to NULL before calling netfsallocfolioqbuffer() as netfs assumes it can append to the buffer it is given. Setting it to NULL means it should start a fresh buffer, but the value is currently undefined.
In the Linux kernel, the following vulnerability has been resolved:
svcrdma: bound check rqpages index in inline path
svcrdmacopyinlinerange indexed rqstp->rqpages[rccurpage] without verifying rccurpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix netfsreadtopagecache() to pause on subreq failure
Fix netfsreadtopagecache() so that it pauses the generation of new subrequests if an already-issued subrequest fails.
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix early put of sink folio in netfsreadgaps()
Fix netfsreadgaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITERBVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps.
The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket:
BUG: KASAN: use-after-free in copytoiter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dumpstacklvl+0x5d/0x80 printreport+0x17f/0x4f1 kasanreport+0x100/0x1e0 kasancheckrange+0x10f/0x1e0 asanmemcpy+0x3c/0x60 copytoiter+0x48a/0xa20 skbdatagramiter+0x2c9/0x430 skbcopydatagramiter+0x6e/0x160 tcprecvmsglocked+0xce0/0x1130 tcprecvmsg+0xeb/0x300 inetrecvmsg+0xcf/0x3a0 sockrecvmsg+0xea/0x100 cifsreadvfromsocket+0x3a6/0x4d0 [cifs] cifsreaditerfromsocket+0xdd/0x130 [cifs] cifsreadvreceive+0xaad/0xb10 [cifs] cifsdemultiplexthread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential UAF in netfsunlockabandonedreadpages()
netfsunlockabandonedreadpages(rreq) accesses the index of the folios it is wanting to unlock and compares that to rreq->nounlockfolio so that it doesn't unlock a folio being read for netfsperformwrite() or netfswritebegin().
However, given that netfsunlockabandonedreadpages() is called after NETFSRREQINPROGRESS is cleared, the one folio that it's not allowed to dereference is the one specified by ->nounlockfolio as ownership immediately reverts to the caller.
Fix this by storing the folio pointer instead and using that rather than the index. Also fix netfsunlockreadfolio() where the same applies.
In the Linux kernel, the following vulnerability has been resolved:
block: recompute nrintegritysegments in blkinsertclonedrequest
blkinsertclonedrequest() already recomputes nrphyssegments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virtboundarymask, segboundarymask, or maxsegmentsize than the top queue, in which case blkrqcountintegritysg() against the bottom queue produces a different count than the cached rq->nrintegritysegments inherited from the source request by blkrqprepclone().
When the cached count is lower than the bottom queue's actual count, blkrqmapintegritysg() trips
BUGON(segments > rq->nrintegritysegments);
on dispatch. The same families of stacked setups that motivated the existing nrphyssegments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this.
Mirror the nrphyssegments handling: when the request carries integrity, recompute nrintegritysegments against the bottom queue and reject the request if it exceeds the bottom queue's maxintegritysegments. blkrqcountintegritysg() and queuemaxintegritysegments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes.
This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Prevent a potential integer overflow
If the tag length is >= U32MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decodecbcompound4res() does not have to perform arithmetic on the unsafe length value.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Move events notifier registration to be after device registration
Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events.
Fix a race between the device deregistration and pkey change work by moving MLX5IBSTAGEDEVICENOTIFIER to be after MLX5IBSTAGEIBREG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below.
BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el91.x8664 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkeychangehandler [mlx5ib] RIP: 0010:setupqp+0x38/0x1f0 [mlx5ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5ibgsipkeychange+0x20/0x40 [mlx5ib] processonework+0x1e8/0x3c0 workerthread+0x50/0x3b0 ? rescuerthread+0x380/0x380 kthread+0x149/0x170 ? setkthreadstruct+0x50/0x50 retfromfork+0x22/0x30 Modules linked in: rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) ibumad(OE) mlx5ib(OE) mlx5fwctl(OE) fwctl(OE) ibuverbs(OE) mlx5core(OE) mlxdevm(OE) ibcore(OE) mlxcompat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfsacl nfs lockd grace fscache netfs qrtr rfkill sunrpc intelraplmsr intelraplcommon rapl hvballoon hvutils i2cpiix4 pcspkr joydev fuse ext4 mbcache jbd2 srmod sdmod cdrom t10pi sg atageneric pcihyperv pcihypervintf hypervdrm drmshmemhelper drmkmshelper hvstorvsc syscopyarea hvnetvsc sysfillrect sysimgblt hidhyperv fbsysfops scsitransportfc hypervkeyboard drm atapiix crct10difpclmul crc32pclmul crc32cintel libata ghashclmulniintel hvvmbus serioraw [last unloaded: ibcore] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]---
Bluetooth: fix use-after-free in deviceforeachchild()
In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Restore context entry setup order for aliased devices
Commit 2031c469f816 ("iommu/vt-d: Add support for static identity domain") changed the context entry setup during domain attachment from a set-and-check policy to a clear-and-reset approach. This inadvertently introduced a regression affecting PCI aliased devices behind PCIe-to-PCI bridges.
Specifically, keyboard and touchpad stopped working on several Apple Macbooks with below messages:
kernel: platform pxa2xx-spi.3: Adding to iommu group 20 kernel: input: Apple SPI Keyboard as /devices/pci0000:00/0000:00:1e.3/pxa2xx-spi.3/spimaster/spi2/spi-APP000D:00/input/input0 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NOPASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NOPASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00 kernel: DMAR: DRHD: handling fault status reg 3 kernel: DMAR: [DMA Read NOPASID] Request device [00:1e.3] fault addr 0xffffa000 [fault reason 0x06] PTE Read access is not set kernel: DMAR: DRHD: handling fault status reg 3 kernel: applespi spi-APP000D:00: Error writing to device: 01 0e 00 00
Fix this by restoring the previous context setup order.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: fix linked list corruption
Never leave scheduled wcid entries on the temporary on-stack list
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix read abandonment during retry
Under certain circumstances, all the remaining subrequests from a read request will get abandoned during retry. The abandonment process expects the 'subreq' variable to be set to the place to start abandonment from, but it doesn't always have a useful value (it will be uninitialised on the first pass through the loop and it may point to a deleted subrequest on later passes).
Fix the first jump to "abandon:" to set subreq to the start of the first subrequest expected to need retry (which, in this abandonment case, turned out unexpectedly to no longer have NEEDRETRY set).
Also clear the subreq pointer after discarding superfluous retryable subrequests to cause an oops if we do try to access it.
In the Linux kernel, the following vulnerability has been resolved:
nsfs: tighten permission checks for ns iteration ioctls
Even privileged services should not necessarily be able to see other privileged service's namespaces so they can't leak information to each other. Use mayseeallnamespaces() helper that centralizes this policy until the nstree adapts.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: use safe list iteration in radar detect work
The call to ieee80211dfscaccancel can cause the iterated chanctx to be freed and removed from the list. Guard against this to avoid a slab-use-after-free error.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.
Fix by acquiring kvm->srcu prior to the table walk in both instances.
In the Linux kernel, the following vulnerability has been resolved:
ice: fix using untrusted value of pktlen in icevcfdirparseraw()
Fix using the untrusted value of proto->raw.pktlen in function icevcfdirparseraw() by verifying if it does not exceed the VIRTCHNLMAXSIZERAWPACKET value.
In the Linux kernel, the following vulnerability has been resolved:
mailbox: mtk-cmdq: fix wrong use of sizeof in cmdqgetclocks()
It should be size of the struct clkbulkdata, not data pointer pass to devmkcalloc().
9p/xen: fix release of IRQ