In the Linux kernel, the following vulnerability has been resolved:
net: tls: prevent chain-after-chain in plain text SG
Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link:
This would create a chain where the wrap link points directly to another chain link. The scatterlist API sgnext iterator does not recursively resolve consecutive chain links.
meaning this is illegal input to crypto.
The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap:
end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]
Skip the wrapping in this case.
TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain.
Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.
In the Linux kernel, the following vulnerability has been resolved:
net: tls: fix off-by-one in sgchain entry count for wrapped skmsg ring
When an skmsg scatterlist ring wraps (sg.end < sg.start), tlspushrecord() chains the tail portion of the ring to the head using sgchain(). An extra entry in the sg array is reserved for this:
struct skmsgsg { [...] / The extra two elements: 1) used for chaining the front and sections when the list becomes partitioned (e.g. end < start). The crypto APIs require the chaining; 2) to chain tailer SG entries after the message. / struct scatterlist data[MAXMSGFRAGS + 2];
The current code uses MAXSKBFRAGS + 1 as the ring size:
sgchain(&msgpl->sg.data[msgpl->sg.start], MAXSKBFRAGS - msgpl->sg.start + 1, msgpl->sg.data);
This places the chain pointer at
sgchain(data[start], (MAXSKBFRAGS - msgstart + 1) .. = &data[start] + (MAXSKBFRAGS - msgstart + 1) - 1 = data[start + (MAXSKBFRAGS - start + 1) - 1] = data[MAXSKBFRAGS]
instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: skmsg, zap ingress queue on psock down")
Convert to ARRAYSIZE and drop the data[start] / - start (as suggested by Sabrina).
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix buffer free/clear order in deferred receive path
Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.
Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: handle getclientlocked() failure in nfsd4setclientidconfirm()
Lei Lu recently reported that nfsd4setclientidconfirm() did not check the return value from getclientlocked(). a SETCLIENTIDCONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.
Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.
In the case where the unconfirmed client is expiring, just fail and return the result from getclientlocked().
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix UAF when detecting digest errors
The Linux kernel CVE team has assigned CVE-2022-48686 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050342-CVE-2022-48686-5e8e@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
ceph: avoid putting the realm twice when decoding snaps fails
When decoding the snaps fails it maybe leaving the 'firstrealm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUGON, etc issues.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4openowner leak when concurrent nfsd4open occur
The action force umount(umount -f) will attempt to kill all rpctask even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpctask to nfs server.
NFS CLIENT thread1 thread2 open("file") ... nfs4doopen nfs4doopen nfs4openandgetstate nfs4procopen nfs4runopentask / rpctask1 / rpcruntask rpcwaitforcompletiontask
umount -f nfsumountbegin rpckillalltasks rpcsignaltask rpctask1 been wakeup and return -512 nfs4doopen // while loop ... nfs4runopentask / rpctask2 / rpcruntask rpcwaitforcompletiontask
While processing an open request, nfsd will first attempt to find or allocate an nfs4openowner. If it finds an nfs4openowner that is not marked as NFS4OOCONFIRMED, this nfs4openowner will released. Since two rpctask can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.
NFS SERVER nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4open nfsd4processopen1 findorallocopenstateowner // alloc oo1, stateid1 nfsd4open nfsd4processopen1 findorallocopenstateowner // find oo1, without NFS4OOCONFIRMED releaseopenowner unhashopenownerlocked listdelinit(&oo->ooperclient) // cannot find this oo // from client, LEAK!!! allocstateowner // alloc oo2
nfsd4processopen2 initopenstateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4getvfsfile // alloc nfsdfile1 and nfsdfilemark1 // all LEAK!!!
nfsd4processopen2 ...
writethreads ... nfsddestroyserv nfsdshutdownnet nfs4stateshutdownnet nfs4statedestroynet destroyclient destroyclient // won't find oo1!!! nfsdshutdowngeneric nfsdfilecacheshutdown kmemcachedestroy for nfsdfileslab and nfsdfilemarkslab // bark since nfsdfile1 // and nfsdfilemark1 // still alive
======================================================================= BUG nfsdfile (Not tainted): Objects remaining in nfsdfile on kmemcacheshutdown() -----------------------------------------------------------------------
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
netrom: check buffer length before accessing it
Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation.
===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25addr.c:119 nrdevget+0x20e/0x450 net/netrom/nrroute.c:601 nrrouteframe+0x1a2/0xfc0 net/netrom/nrroute.c:774 nrxmit+0x5a/0x1c0 net/netrom/nrdev.c:144 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3548 [inline] devhardstartxmit+0x247/0xa10 net/core/dev.c:3564 devqueuexmit+0x33b8/0x5130 net/core/dev.c:4349 devqueuexmit include/linux/netdevice.h:3134 [inline] rawsendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154socksendmsg+0x91/0xc0 net/ieee802154/socket.c:96 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
Uninit was created at: slabpostallochook+0x129/0xa70 mm/slab.h:768 slaballocnode mm/slub.c:3478 [inline] kmemcacheallocnode+0x5e9/0xb10 mm/slub.c:3523 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:560 allocskb+0x318/0x740 net/core/skbuff.c:651 allocskb include/linux/skbuff.h:1286 [inline] allocskbwithfrags+0xc8/0xbd0 net/core/skbuff.c:6334 sockallocsendpskb+0xa80/0xbf0 net/core/sock.c:2780 sockallocsendskb include/net/sock.h:1884 [inline] rawsendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154socksendmsg+0x91/0xc0 net/ieee802154/socket.c:96 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 =====================================================
This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nrrouteframe does not validate the buffer size before using it.
Fix this issue by checking skb->len before accessing any fields in skb->data.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
In the Linux kernel, the following vulnerability has been resolved:
nfs: Fix KMSAN warning in decodegetfattrattrs()
Fix the following KMSAN warning:
CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BADPAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrattrs+0x2d6d/0x2f90 decodegetfattrgeneric+0x806/0xb00 nfs4xdrdecgetattr+0x1de/0x240 rpcauthunwraprespdecode+0xab/0x100 rpcauthunwrapresp+0x95/0xc0 calldecode+0x4ff/0xb50 rpcexecute+0x57b/0x19d0 rpcexecute+0x368/0x5e0 rpcruntask+0xcfe/0xee0 nfs4procgetattr+0x5b5/0x990 nfsrevalidateinode+0x477/0xd00 nfsaccessgetcached+0x1021/0x1cc0 nfsdoaccess+0x9f/0xae0 nfspermission+0x1e4/0x8c0 inodepermission+0x356/0x6c0 linkpathwalk+0x958/0x1330 pathlookupat+0xce/0x6b0 filenamelookup+0x23e/0x770 vfsstatx+0xe7/0x970 vfsfstatat+0x1f2/0x2c0 sesysnewfstatat+0x67/0x880 x64sysnewfstatat+0xbd/0x120 x64syscall+0x1826/0x3cf0 dosyscall64+0xd0/0x1b0 entrySYSCALL64afterhwframe+0x77/0x7f
The KMSAN warning is triggered in decodegetfattrattrs(), when calling decodeattrmdsthreshold(). It appears that fattr->mdsthreshold is not initialized.
Fix the issue by initializing fattr->mdsthreshold to NULL in nfsfattrinit().
In the Linux kernel, the following vulnerability has been resolved:
nvme-rdma: fix possible use-after-free in transport errorrecovery work
While nvmerdmasubmitasynceventwork is checking the ctrl and queue state before preparing the AER command and scheduling iowork, in order to fully prevent a race where this check is not reliable the error recovery work must flush asynceventwork before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submitasyncevent and the error recovery handler itself changing the ctrl state.
In the Linux kernel, the following vulnerability has been resolved:
drm/sched: Avoid data corruptions
Wait for all dependencies of a job to complete before killing it to avoid data corruptions.
hfsplus: fix slab-out-of-bounds in hfsplusbnoderead()
In the Linux kernel, the following vulnerability has been resolved:
drbd: add missing krefget in handlewriteconflicts
With two-primaries enabled, DRBD tries to detect "concurrent" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed.
In handling "superseeded" writes, we forgot a krefget, resulting in a premature drbddestroydevice and use after free, and further to kernel crashes with symptoms.
Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.
Which means that other than for "test cases", this code path is never taken in real life.
FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.
bnxten: Set DMA unmap len correctly for XDPREDIRECT
In the Linux kernel, the following vulnerability has been resolved:
nfsd: nfsd4spomustallow() must check this is a v4 compound request
If the request being processed is not a v4 compound request, then examining the cstate can have undefined results.
This patch adds a check that the rpc procedure being executed (rqprocinfo) is the NFSPROC4COMPOUND procedure.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix use-after-free of work objects after cmid destruction
The commit 59c68ac31e15 ("iwcm: free cmid resources on the last deref") simplified cmid resource management by freeing cmid once all references to the cmid were removed. The references are removed either upon completion of iwcm event handlers or when the application destroys the cmid. This commit introduced the use-after-free condition where cmidprivate object could still be in use by event handler works during the destruction of cmid. The commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs") addressed this use-after- free by flushing all pending works at the cmid destruction.
However, still another use-after-free possibility remained. It happens with the work objects allocated for each cmidpriv within allocworkentries() during cmid creation, and subsequently freed in deallocworkentries() once all references to the cmid are removed. If the cmid's last reference is decremented in the event handler work, the work object for the work itself gets removed, and causes the use- after-free BUG below:
BUG: KASAN: slab-use-after-free in pwqactivatework+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091
CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iwcmwq) Call Trace: <TASK> dumpstacklvl+0x6a/0x90 printreport+0x174/0x554 ? virtaddrvalid+0x208/0x430 ? pwqactivatework+0x1ff/0x250 kasanreport+0xae/0x170 ? pwqactivatework+0x1ff/0x250 pwqactivatework+0x1ff/0x250 pwqdecnrinflight+0x8c5/0xfb0 processonework+0xc11/0x1460 ? pfxprocessonework+0x10/0x10 ? assignwork+0x16c/0x240 workerthread+0x5ef/0xfd0 ? pfxworkerthread+0x10/0x10 kthread+0x3b0/0x770 ? pfxkthread+0x10/0x10 ? rcuiswatching+0x11/0xb0 ? rawspinunlockirq+0x24/0x50 ? rcuiswatching+0x11/0xb0 ? pfxkthread+0x10/0x10 retfromfork+0x30/0x70 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
Allocated by task 147416: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasankmalloc+0xa6/0xb0 allocworkentries+0xa9/0x260 [iwcm] iwcmconnect+0x23/0x4a0 [iwcm] rdmaconnectlocked+0xbfd/0x1920 [rdmacm] nvmerdmacmhandler+0x8e5/0x1b60 [nvmerdma] cmacmeventhandler+0xae/0x320 [rdmacm] cmaworkhandler+0x106/0x1b0 [rdmacm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30
Freed by task 147091: kasansavestack+0x2c/0x50 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 kasanslabfree+0x4b/0x70 kfree+0x13a/0x4b0 deallocworkentries+0x125/0x1f0 [iwcm] iwcmderefid+0x6f/0xa0 [iwcm] cmworkhandler+0x136/0x1ba0 [iwcm] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30
Last potentially related work creation: kasansavestack+0x2c/0x50 kasanrecordauxstack+0xa3/0xb0 queuework+0x2ff/0x1390 queueworkon+0x67/0xc0 cmeventhandler+0x46a/0x820 [iwcm] siwcmupcall+0x330/0x650 [siw] siwcmworkhandler+0x6b9/0x2b20 [siw] processonework+0x84f/0x1460 workerthread+0x5ef/0xfd0 kthread+0x3b0/0x770 retfromfork+0x30/0x70 retfromforkasm+0x1a/0x30
This BUG is reproducible by repeating the blktests test case nvme/061 for the rdma transport and the siw driver.
To avoid the use-after-free of cmidprivate work objects, ensure that the last reference to the cmid is decremented not in the event handler works, but in the cmid destruction context. For that purpose, mo ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Fix the dead loop of MPLS parse
The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally.
stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type 'be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: <IRQ> showstack+0x52/0x5c dumpstacklvl+0x4a/0x63 dumpstack+0x10/0x16 ubsanepilogue+0x9/0x36 ubsanhandleoutofbounds.cold+0x44/0x49 keyextractl3l4+0x82a/0x840 [openvswitch] ? kfreeskbmem+0x52/0xa0 keyextract+0x9c/0x2b0 [openvswitch] ovsflowkeyextract+0x124/0x350 [openvswitch] ovsvportreceive+0x61/0xd0 [openvswitch] ? kernelinitfreepages.part.0+0x4a/0x70 ? getpagefromfreelist+0x353/0x540 netdevportreceive+0xc4/0x180 [openvswitch] ? netdevportreceive+0x180/0x180 [openvswitch] netdevframehook+0x1f/0x40 [openvswitch] netifreceiveskbcore.constprop.0+0x23a/0xf00 netifreceiveskblistcore+0xfa/0x240 netifreceiveskblistinternal+0x18e/0x2a0 napicompletedone+0x7a/0x1c0 bnxtpoll+0x155/0x1c0 [bnxten] napipoll+0x30/0x180 netrxaction+0x126/0x280 ? bnxtmsix+0x67/0x80 [bnxten] handlesoftirqs+0xda/0x2d0 irqexitrcu+0x96/0xc0 commoninterrupt+0x8e/0xa0 </IRQ>
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix timeout on deleted connection
NOPIN response timer may expire on a deleted connection and crash with such logs:
Did not receive response to NOPIN on CID: 0, failing connection for IT Nexus (null),i,0x00023d000125,iqn.2017-01.com.iscsi.target,t,0x3d
BUG: Kernel NULL pointer dereference on read at 0x00000000 NIP strlcpy+0x8/0xb0 LR iscsitfillcxntimeouterrstats+0x5c/0xc0 [iscsitargetmod] Call Trace: iscsithandlenopinresponsetimeout+0xfc/0x120 [iscsitargetmod] calltimerfn+0x58/0x1f0 runtimersoftirq+0x740/0x860 dosoftirq+0x16c/0x420 irqexit+0x188/0x1c0 timerinterrupt+0x184/0x410
That is because nopin response timer may be re-started on nopin timer expiration.
Stop nopin timer before stopping the nopin response timer to be sure that no one of them will be re-started.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: socket: Lookup orig tuple for IPv6 SNAT
nfsklookupslowv4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socketmatch() can correctly check whether the socket was transparent.
However, the IPv6 counterpart (nfsklookupslowv6) lacks this conntrack lookup, making xtsocket fail to match on the socket when the packet was SNATed. Add the same logic to nfsklookupslowv6.
IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on -m socket --transparent and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.
In the Linux kernel, the following vulnerability has been resolved:
can: j1939: j1939sessionnew(): fix skb reference counting
Since j1939sessionskbqueue() does an extra skbget() for each new skb, do the same for the initial one in j1939sessionnew() to avoid refcount underflow.
[mkl: clean up commit message]
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:
NFSv4: Prevent NULL-pointer dereference in nfs42completecopies()
On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42completecopies() got a NULL-pointer dereference crash with the following syslog:
[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsecgsskrb5 authrpcgss nfsv4 dnsresolver nfs lockd grace fscache netfs ocfs2dlmfs ocfs2stacko2cb ocfs2dlm vhostnet vhost vhostiotlb tap tun iptrpfilter xtmultiport ipsethaship ipsethashnet xfrminterface xfrm6tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519generic veth xtaddrtype xtset nfconntracknetlink ipsethashipportnet ipsethashipportip ipsetbitmapport ipsethashipport dummy ipset ipvssh ipvswrr ipvsrr ipvs iptablefilter schingress nfnetlinkcttimeout vportgre ipgre iptunnel gre vportgeneve geneve vportvxlan vxlan ip6udptunnel udptunnel openvswitch nfconncount dmroundrobin dmservicetime dmmultipath xtnat xtMASQUERADE nftchainnat nfnat xtmark xtconntrack xtcomment nftcompat nftcounter nftables nfnetlink ocfs2 ocfs2nodemanager ocfs2stackglue iscsitcp libiscsitcp libiscsi scsitransportiscsi ipmissif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cascache casdisk ses enclosure scsitransportsas sg acpiipmi ipmisi ipmidevintf ipmimsghandler iptables vfiopci vfiopcicore vfiovirqfd vfioiommutype1 vfio dmmirror dmregionhash dmlog dmmod nfconntrack nfdefragipv6 nfdefragipv4 brnetfilter bridge stp llc fuse xfs libcrc32c ast drmvramhelper qla2xxx drmkmshelper syscopyarea crct10difce sysfillrect ghashce sysimgblt sha2ce fbsysfops cec sha256arm64 sha1ce drmttmhelper ttm nvmefc igb sbsagwdt nvmefabrics drm nvmecore i2calgobit i40e scsitransportfc megaraidsas aesneonbs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBEV3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4reclaimopenstate+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4reclaimopenstate+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix buffer overflow when parsing NFS reparse points
ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength.
Function cifsstrndupfromutf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len.
Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access.
Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparsemkdev().
In the Linux kernel, the following vulnerability has been resolved:
smack: tcp: ipv4, fix incorrect labeling
Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write.
Here is a scenario how to see this:
Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels)
At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment)
At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections
From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works.
Send some data in both directions. Collect network traffic of this connection.
All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C.
If anybody cares: exactly the same happens with DCCP.
This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided.
I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.
In the Linux kernel, the following vulnerability has been resolved:
atm: idt77252: prevent use after free in dequeuerx()
We can't dereference "skb" after calling vcc->push() because the skb is released.
In the Linux kernel, the following vulnerability has been resolved:
usb: vhci-hcd: Do not drop references before new references are gained
At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix a use-after-free related to destroying CM IDs
iwconnreqhandler() associates a new struct rdmaidprivate (connid) with an existing struct iwcmid (cmid) as follows:
connid->cmid.iw = cmid; cmid->context = connid; cmid->cmhandler = cmaiwhandler;
rdmadestroyid() frees both the cmid and the struct rdmaidprivate. Make sure that cmworkhandler() does not trigger a use-after-free by only freeing of the struct rdmaidprivate after all pending work has finished.
In the Linux kernel, the following vulnerability has been resolved:
tipc: Return non-zero value from tipcudpaddr2str() on error
tipcudpaddr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipcmediaaddrprintf(). Fix this by returning 1 on an invalid UDP media address.
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix race between delayedwork() and cephmoncstop()
The way the delayed work is handled in cephmoncstop() is prone to races with monfault() and possibly also finishhunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after canceldelayedworksync() runs -- closesession() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in monfault() if curmon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused.
To fix this:
- clear monc->curmon and monc->hunting as part of closing the session in cephmoncstop() - bail from delayedwork() if monc->curmon is cleared, similar to how it's done in monfault() and finishhunting() (based on monc->hunting) - call canceldelayedworksync() after the session is closed
In the Linux kernel, the following vulnerability has been resolved:
ila: block BH in ilaoutput()
As explained in commit 1378817486d6 ("tipc: block BH before using dstcache"), net/core/dstcache.c helpers need to be called with BH disabled.
ilaoutput() is called from lwtunneloutput() possibly from process context, and under rcureadlock().
We might be interrupted by a softirq, re-enter ilaoutput() and corrupt dstcache data structures.
Fix the race by using localbhdisable().