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:
lwt: Fix return values of BPF xmit ops
BPF encap ops can return different types of positive values, such like NETRXDROP, NETXMITCN, NETDEVTXBUSY, and so on, from function skbdoredirect and bpflwtxmitreroute. At the xmit hook, such return values would be treated implicitly as LWTUNNELXMITCONTINUE in ip(6)finishoutput2. When this happens, skbs that have been freed would continue to the neighbor subsystem, causing use-after-free bug and kernel crashes.
To fix the incorrect behavior, skbdoredirect return values can be simply discarded, the same as tc-egress behavior. On the other hand, bpflwtxmitreroute returns useful errors to local senders, e.g. PMTU information. Thus convert its return values to avoid the conflict with LWTUNNELXMITCONTINUE.
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().
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:
nvmet: avoid potential UAF in nvmetreqcomplete()
An nvme target ->queueresponse() operation implementation may free the request passed as argument. Such implementation potentially could result in a use after free of the request pointer when percpurefput() is called in nvmetreqcomplete().
Avoid such problem by using a local variable to save the sq pointer before calling nvmetreqcomplete(), thus avoiding dereferencing the req pointer after that function call.
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:
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:
cifs: Fix oops due to uncleared server->smbdconn in reconnect
In smbddestroy(), clear the server->smbdconn pointer after freeing the smbdconnection struct that it points to so that reconnection doesn't get confused.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: re-fetch conntrack after insertion
In case the conntrack is clashing, insertion can free skb->nfct and set skb->nfct to the already-confirmed entry.
This wasn't found before because the conntrack entry and the extension space used to free'd after an rcu grace period, plus the race needs events enabled to trigger.
In the Linux kernel, the following vulnerability has been resolved:
dlm: fix plock invalid read
This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plockop" and a followed sendop() will append it to a global sendlist data structure. In some cases a followed devread() moves it to recvlist and devwrite() will cast it to "struct plockxop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields.
To fix this issue the "callback" field is moved to "struct plockop" to indicate that a cast to "plockxop" is allowed and does the additional "plockxop" handling if set.
Example of the KASAN output which showed the invalid read:
[ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in devwrite+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlmcontrold/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlmcontrold Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dumpstacklvl+0x56/0x7b [ 2064.313150] printaddressdescription.constprop.8+0x21/0x150 [ 2064.314578] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.315610] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.316595] kasanreport.cold.14+0x7f/0x11b [ 2064.317674] ? devwrite+0x52b/0x5a0 [dlm] [ 2064.318687] devwrite+0x52b/0x5a0 [dlm] [ 2064.319629] ? devread+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpflsmkernfsinitsecurity+0x10/0x10 [ 2064.321926] vfswrite+0x17e/0x930 [ 2064.322769] ? fgetlight+0x1aa/0x220 [ 2064.323753] ksyswrite+0xf1/0x1c0 [ 2064.324548] ? ia32sysread+0xb0/0xb0 [ 2064.325464] dosyscall64+0x3a/0x80 [ 2064.326387] entrySYSCALL64afterhwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIGRAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasansavestack+0x1c/0x40 [ 2064.345079] kasankmalloc+0x84/0xa0 [ 2064.345933] kmemcachealloctrace+0x13b/0x220 [ 2064.346953] dlmposixunlock+0xec/0x720 [dlm] [ 2064.348811] dolockfilewait.part.32+0xca/0x1d0 [ 2064.351070] fcntlsetlk+0x281/0xbc0 [ 2064.352879] dofcntl+0x5e4/0xfe0 [ 2064.354657] x64sysfcntl+0x11f/0x170 [ 2064.356550] dosyscall64+0x3a/0x80 [ 2064.358259] entrySYSCALL64afterhwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasansavestack+0x1c/0x40 [ 2064.365811] kasanrecordauxstack+0xaf/0xc0 [ 2064.368100] callrcu+0x11b/0xf70 [ 2064.369785] dlmprocessincomingbuffer+0x47d/0xfd0 [dlm] [ 2064.372404] receivefromsock+0x290/0x770 [dlm] [ 2064.374607] processrecvsockets+0x32/0x40 [dlm] [ 2064.377290] processonework+0x9a8/0x16e0 [ 2064.379357] workerthread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] retfromfork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasansavestack+0x1c/0x40 [ 2064.391043] kasanrecordauxstack+0xaf/0xc0 [ 2064.393303] callrcu+0x11b/0xf70 [ 2064.394885] dlmprocessincomingbuffer+0x47d/0xfd0 [dlm] [ 2064.397694] receivefromsock+0x290/0x770 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
NFSD: prevent underflow in nfssvcdecodewriteargs()
Smatch complains:
fs/nfsd/nfsxdr.c:341 nfssvcdecodewriteargs() warn: no lower bound on 'args->len'
Change the type to unsigned to prevent this issue.
In the Linux kernel, the following vulnerability has been resolved:
net/tls: fix slab-out-of-bounds bug in decryptinternal
The memory size of tlsctx->rx.iv for AES128-CCM is 12 setting in tlssetswoffload(). The return value of cryptoaeadivsize() for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes memory space will trigger slab-out-of-bounds bug as following:
================================================================== BUG: KASAN: slab-out-of-bounds in decryptinternal+0x385/0xc40 [tls] Read of size 16 at addr ffff888114e84e60 by task tls/10911
Call Trace: <TASK> dumpstacklvl+0x34/0x44 printreport.cold+0x5e/0x5db ? decryptinternal+0x385/0xc40 [tls] kasanreport+0xab/0x120 ? decryptinternal+0x385/0xc40 [tls] kasancheckrange+0xf9/0x1e0 memcpy+0x20/0x60 decryptinternal+0x385/0xc40 [tls] ? tlsgetrec+0x2e0/0x2e0 [tls] ? processrxlist+0x1a5/0x420 [tls] ? tlssetupfromiter.constprop.0+0x2e0/0x2e0 [tls] decryptskbupdate+0x9d/0x400 [tls] tlsswrecvmsg+0x3c8/0xb50 [tls]
Allocated by task 10911: kasansavestack+0x1e/0x40 kasankmalloc+0x81/0xa0 tlssetswoffload+0x2eb/0xa20 [tls] tlssetsockopt+0x68c/0x700 [tls] syssetsockopt+0xfe/0x1b0
Replace the cryptoaeadivsize() with prot->ivsize + prot->saltsize when memcpy() iv value in TLS13VERSION scenario.
In the Linux kernel, the following vulnerability has been resolved:
cifs: potential buffer overflow in handling symlinks
Smatch printed a warning: arch/x86/crypto/poly1305glue.c:198 poly1305updatearch() error: memcpy() 'dctx->buf' too small (16 vs u32max)
It's caused because Smatch marks 'linklen' as untrusted since it comes from sscanf(). Add a check to ensure that 'linklen' is not larger than the size of the 'linkstr' buffer.
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:
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:
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:
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:
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:
netfilter: nfrejectipv6: fix nfrejectip6tcphdrput()
syzbot reported that nfrejectip6tcphdrput() was possibly sending garbage on the four reserved tcp bits (th->res1)
Use skbputzero() to clear the whole TCP header, as done in nfrejectiptcphdrput()
BUG: KMSAN: uninit-value in nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfrejectip6tcphdrput+0x688/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:255 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore net/core/dev.c:5661 [inline] netifreceiveskb+0x1da/0xa00 net/core/dev.c:5775 processbacklog+0x4ad/0xa50 net/core/dev.c:6108 napipoll+0xe7/0x980 net/core/dev.c:6772 napipoll net/core/dev.c:6841 [inline] netrxaction+0xa5a/0x19b0 net/core/dev.c:6963 handlesoftirqs+0x1ce/0x800 kernel/softirq.c:554 dosoftirq+0x14/0x1a kernel/softirq.c:588 dosoftirq+0x9a/0x100 kernel/softirq.c:455 localbhenableip+0x9f/0xb0 kernel/softirq.c:382 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:908 [inline] devqueuexmit+0x2692/0x5610 net/core/dev.c:4450 devqueuexmit include/linux/netdevice.h:3105 [inline] neighresolveoutput+0x9ca/0xae0 net/core/neighbour.c:1565 neighoutput include/net/neighbour.h:542 [inline] ip6finishoutput2+0x2347/0x2ba0 net/ipv6/ip6output.c:141 ip6finishoutput net/ipv6/ip6output.c:215 [inline] ip6finishoutput+0xbb8/0x14b0 net/ipv6/ip6output.c:226 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x356/0x620 net/ipv6/ip6output.c:247 dstoutput include/net/dst.h:450 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6xmit+0x1ba6/0x25d0 net/ipv6/ip6output.c:366 inet6cskxmit+0x442/0x530 net/ipv6/inet6connectionsock.c:135 tcptransmitskb+0x3b07/0x4880 net/ipv4/tcpoutput.c:1466 tcptransmitskb net/ipv4/tcpoutput.c:1484 [inline] tcpconnect+0x35b6/0x7130 net/ipv4/tcpoutput.c:4143 tcpv6connect+0x1bcc/0x1e40 net/ipv6/tcpipv6.c:333 inetstreamconnect+0x2ef/0x1730 net/ipv4/afinet.c:679 inetstreamconnect+0x6a/0xd0 net/ipv4/afinet.c:750 sysconnectfile net/socket.c:2061 [inline] sysconnect+0x606/0x690 net/socket.c:2078 dosysconnect net/socket.c:2088 [inline] sesysconnect net/socket.c:2085 [inline] x64sysconnect+0x91/0xe0 net/socket.c:2085 x64syscall+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls64.h:43 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f
Uninit was stored to memory at: nfrejectip6tcphdrput+0x60c/0x6c0 net/ipv6/netfilter/nfrejectipv6.c:249 nfsendreset6+0xd84/0x15b0 net/ipv6/netfilter/nfrejectipv6.c:344 nftrejectineteval+0x3c1/0x880 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x438/0x22a0 net/netfilter/nftablescore.c:288 nftdochaininet+0x41a/0x4f0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf4/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x29b/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore ---truncated---
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.