In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVSPACKETCMDEXECUTE has 3 main attributes: - OVSPACKETATTRKEY - Packet metadata in a netlink format. - OVSPACKETATTRPACKET - Binary packet content. - OVSPACKETATTRACTIONS - Actions to execute on the packet.
OVSPACKETATTRKEY is parsed first to populate swflowkey structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers.
Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.
It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ctorig' that holds the original tuple conntrack metadata parsed from the OVSPACKETATTRKEY.
ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten.
The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace.
ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.
Initializing the whole thing before parsing is needed because ND packet may not contain all the options.
The issue only affects the OVSPACKETCMDEXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.
Incorrect verifier pruning in BPF in Linux Kernel >=5.4 leads to unsafe code paths being incorrectly marked as safe, resulting in arbitrary read/write in kernel memory, lateral privilege escalation, and container escape.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix race condition between session lookup and expire
Thread A + Thread B ksmbdsessionlookup | smb2sesssetup sess = xaload | | | xaerase(&conn->sessions, sess->id); | | ksmbdsessiondestroy(sess) --> kfree(sess) | // UAF! | sess->lastactive = jiffies | +
This patch add rwsem to fix race condition between ksmbdsessionlookup and ksmbdexpiresession.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Do not call scsidone() from srpabort()
After scmdehaborthandler() has called the SCSI LLD ehaborthandler callback, it performs one of the following actions: Call scsiqueueinsert(). Call scsifinishcommand(). Call scsiehscmdadd(). Hence, SCSI abort handlers must not call scsidone(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsidone() call from srpabort(). Keep the srpfreereq() call before returning SUCCESS because we may not see the command again if SUCCESS is returned.
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix a use-after-free
Fix the following use-after-free complaint triggered by blktests nvme/004:
BUG: KASAN: user-memory-access in blkmqcompleterequestremote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvmeloopexecutework [nvmeloop] Call Trace: showstack+0x52/0x58 dumpstacklvl+0x49/0x5e printreport.cold+0x36/0x1e2 kasanreport+0xb9/0xf0 asanload4+0x6b/0x80 blkmqcompleterequestremote+0xac/0x350 nvmeloopqueueresponse+0x1df/0x275 [nvmeloop] nvmetreqcomplete+0x132/0x4f0 [nvmet] nvmetreqcomplete+0x15/0x40 [nvmet] nvmetexecuteioconnect+0x18a/0x1f0 [nvmet] nvmeloopexecutework+0x20/0x30 [nvmeloop] processonework+0x56e/0xa70 workerthread+0x2d1/0x640 kthread+0x183/0x1c0 retfromfork+0x1f/0x30
In the Linux kernel, the following vulnerability has been resolved:
of: module: add buffer overflow check in ofmodalias()
In ofmodalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix invalid unregister error path
The error path of seg6init() is wrong in case CONFIGIPV6SEG6LWTUNNEL is not defined. In that case if seg6hmacinit() fails, the genlunregisterfamily() isn't called.
This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregisterpernetsubsys() with genlunregisterfamily() in this error path.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: codecs: wcd938x: fix incorrect used of portid
Mixer controls have the channel id in mixer->reg, which is not same as port id. port id should be derived from chaninfo array. So fix this. Without this, its possible that we could corrupt struct wcd938xsdwpriv by accessing portmap array out of range with channel id instead of port id.
In the Linux kernel, the following vulnerability has been resolved:
nvme: avoid double free special payload
If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQFSPECIALLOAD when the request is cleaned.
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:
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/rtrs-clt: Reset cid to connum - 1 to stay in bounds
In the function initconns(), after the createcon() and createcm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to cltpath->s.connum.
This commits resets the cid to cltpath->s.connum - 1, to stay in bounds in the cleanup loop later.
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:
net: mana: Fix race on per-CQ variable napi workdone
After calling napicompletedone(), the NAPIFSTATESCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->workdone. If the other thread (for example, from busypoll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic.
To fix this issue, save the per-CQ workdone variable in a local variable before napicompletedone(), so it won't be corrupted by a possible concurrent thread after napicompletedone().
Also, add a flag bit to advertise to the NIC firmware: the NAPI workdone variable race is fixed, so the driver is able to reliably support features like busypoll.
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix SRCU protection of nvmenshead list
Walking the nvmenshead siblings list is protected by the head's srcu in nvmensheadsubmitbio() but not nvmempathrevalidatepaths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees.
Hold the head's srcu lock in nvmempathrevalidatepaths() and synchronize with the srcu, not the global RCU, in nvmensremove().
Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != getcapacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic).
[37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x8664 #1 [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018 [37314.299763] Workqueue: nvme-wq nvmescanwork [nvmecore] [37314.299783] RIP: 0010:nvmempathrevalidatepaths+0x26/0xb0 [nvmecore] [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Call Trace: [37315.828515] nvmeupdatensinfo+0x1ac/0x250 [nvmecore] [37315.892075] nvmevalidateorallocns+0x2ff/0xa00 [nvmecore] [37315.961871] ? blkmqfreerequest+0x6b/0x90 [37316.015021] nvmescanwork+0x151/0x240 [nvmecore] [37316.073371] processonework+0x1a7/0x360 [37316.121318] ? createworker+0x1a0/0x1a0 [37316.168227] workerthread+0x30/0x390 [37316.212024] ? createworker+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? setkthreadstruct+0x50/0x50 [37316.347590] retfromfork+0x35/0x40 [37316.390360] Modules linked in: nvmerdma nvmetcp(X) nvmefabrics nvmecore netconsole iscsitcp libiscsitcp dmqueuelength dmservicetime nfconntracknetlink brnetfilter bridge stp llc overlay nftchainnat iptMASQUERADE nfnat xtaddrtype xtCT nftcounter xtstate xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment xtmultiport nftcompat nftables libcrc32c nfnetlink dmmultipath tg3 rpcrdma sunrpc rdmaucm ibsrpt ibisert iscsitargetmod targetcoremod ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm intelraplmsr iTCOwdt iTCOvendorsupport dcdbas intelraplcommon sbedac x86pkgtempthermal intelpowerclamp coretemp kvmintel ipmissif kvm irqbypass crct10difpclmul crc32pclmul mlx5ib ghashclmulniintel ibuverbs rapl intelcstate inteluncore ibcore ipmisi joydev meime pcspkr ipmidevintf mei lpcich wmi ipmimsghandler acpipowermeter ex ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
tcp/dccp: Don't use timerpending() in reqskqueueunlink().
Martin KaFai Lau reported use-after-free [0] in reqsktimerhandler().
""" We are seeing a use-after-free from a bpf prog attached to tracetcpretransmitsynack. The program passes the req->sk to the bpfskstoragegettracing kernel helper which does check for null before using it. """
The commit 83fccfc3940c ("inet: fix potential deadlock in reqskqueueunlink()") added timerpending() in reqskqueueunlink() not to call deltimersync() from reqsktimerhandler(), but it introduced a small race window.
Before the timer is called, expiretimers() calls detachtimer(timer, true) to clear timer->entry.pprev and marks it as not pending.
If reqskqueueunlink() checks timerpending() just after expiretimers() calls detachtimer(), TCP will miss deltimersync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.
The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default.
The scenario would be
1. inetcskcompletehashdance() calls inetcskreqskqueuedrop(), but deltimersync() is missed
2. reqsk timer is executed and scheduled again
3. req->sk is accept()ed and reqskput() decrements rskrefcnt, but reqsk timer still has another one, and inetcskaccept() does not clear req->sk for non-TFO sockets
4. sk is close()d
5. reqsk timer is executed again, and BPF touches req->sk
Let's not use timerpending() by passing the caller context to inetcskreqskqueuedrop().
Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]
[0] BUG: KFENCE: use-after-free read in bpfskstoragegettracing+0x2e/0x1b0
Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpfskstoragegettracing+0x2e/0x1b0 bpfprog5ea3e95db6da0438tcpretransmitsynack+0x1d20/0x1dda bpftracerun2+0x4c/0xc0 tcprtxsynack+0xf9/0x100 reqsktimerhandler+0xda/0x3d0 runtimersoftirq+0x292/0x8a0 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 intelidleirq+0x5a/0xa0 cpuidleenterstate+0x94/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6
allocated by task 0 on cpu 9 at 260507.901592s: skprotalloc+0x35/0x140 skclonelock+0x1f/0x3f0 inetcskclonelock+0x15/0x160 tcpcreateopenreqchild+0x1f/0x410 tcpv6synrecvsock+0x1da/0x700 tcpcheckreq+0x1fb/0x510 tcpv6rcv+0x98b/0x1420 ipv6listrcv+0x2258/0x26e0 napicompletedone+0x5b1/0x2990 mlx5enapipoll+0x2ae/0x8d0 netrxaction+0x13e/0x590 irqexitrcu+0xf5/0x320 commoninterrupt+0x80/0x90 asmcommoninterrupt+0x22/0x40 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
freed by task 0 on cpu 9 at 260507.927527s: rcucoresi+0x4ff/0xf10 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix LGR and link use-after-free issue
We encountered a LGR/link use-after-free issue, which manifested as the LGR/link refcnt reaching 0 early and entering the clear process, making resource access unsafe.
refcountt: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcountwarnsaturate+0x9c/0x140 Workqueue: events smclgrterminatework [smc] Call trace: refcountwarnsaturate+0x9c/0x140 smclgrterminate.part.45+0x2a8/0x370 [smc] smclgrterminatework+0x28/0x30 [smc] processonework+0x1b8/0x420 workerthread+0x158/0x510 kthread+0x114/0x118
or
refcountt: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcountwarnsaturate+0xf0/0x140 Workqueue: smchswq smclistenwork [smc] Call trace: refcountwarnsaturate+0xf0/0x140 smcrlinkput+0x1cc/0x1d8 [smc] smcconnfree+0x110/0x1b0 [smc] smcconnabort+0x50/0x60 [smc] smclistenfinddevice+0x75c/0x790 [smc] smclistenwork+0x368/0x8a0 [smc] processonework+0x1b8/0x420 workerthread+0x158/0x510 kthread+0x114/0x118
It is caused by repeated release of LGR/link refcnt. One suspect is that smcconnfree() is called repeatedly because some smcconnfree() from server listening path are not protected by sock lock.
e.g.
Calls under socklock | smclistenwork ------------------------------------------------------- locksock(sk) | smcconnabort smcconnfree | \- smcconnfree \- smcrlinkput | \- smcrlinkput (duplicated) releasesock(sk)
So here add sock lock protection in smclistenwork() path, making it exclusive with other connection operations.
In the Linux kernel, the following vulnerability has been resolved:
skbuff: fix coalescing for pagepool fragment recycling
Fix a use-after-free when using pagepool with page fragments. We encountered this problem during normal RX in the hns3 driver:
(1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through pagepool, and the other two allocate one half of PAGE2 each. Page references look like this:
RXBD1 PAGE1 RXBD2 PAGE2 RXBD3 /
(2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcpqueuercv().
(3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netifreceiveskb():
netifreceiveskb(SKB2) iprcv(SKB2) SKB3 = skbclone(SKB2)
SKB2 and SKB3 share a reference to PAGE2 through skbshinfo()->dataref. The other ref to PAGE2 is still held by RXBD3:
SKB2 ---+- PAGE2 SKB3 / / RXBD3 /
(3b) Now while handling TCP, coalesce SKB3 with SKB1:
tcpv4rcv(SKB3) tcptrycoalesce(to=SKB1, from=SKB3) // succeeds kfreeskbpartial(SKB3) skbreleasedata(SKB3) // drops one dataref
SKB1 PAGE1 \ SKB2 PAGE2 / RXBD3 /
In skbtrycoalesce(), skbfragref() takes a page reference to PAGE2, where it should instead have increased the pagepool frag reference, ppfragcount. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow.
(3c) Drop SKB2:
afpacketrcv(SKB2) consumeskb(SKB2) skbreleasedata(SKB2) // drops second dataref pagepoolreturnskbpage(PAGE2) // drops one ppfragcount
SKB1 PAGE1 \ PAGE2 / RXBD3 /
(4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well:
tcpeatrecvskb(SKB1) skbreleasedata(SKB1) pagepoolreturnskbpage(PAGE1) pagepoolreturnskbpage(PAGE2) // drops second ppfragcount
(5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled.
Change the logic that checks whether pprecycle SKBs can be coalesced. We still reject differing pprecycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pprecycled and 'from' is cloned.
The new logic allows coalescing a cloned pprecycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skbtrycoalesce().
In the Linux kernel, the following vulnerability has been resolved:
In the Linux kernel, the following vulnerability has been resolved:
crypto: hisilicon/sec - fix the aead software fallback for engine
Due to the subreq pointer misuse the private context memory. The aead soft crypto occasionally casues the OS panic as setting the 64K page. Here is fix it.
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:
NFSv4: Fix free of uninitialized nfs4label on referral lookup.
Send along the already-allocated fattr along with nfs4fslocations, and drop the memcpy of fattr. We end up growing two more allocations, but this fixes up a crash as:
PID: 790 TASK: ffff88811b43c000 CPU: 0 COMMAND: "ls" #0 [ffffc90000857920] panic at ffffffff81b9bfde #1 [ffffc900008579c0] dotrap at ffffffff81023a9b #2 [ffffc90000857a10] doerrortrap at ffffffff81023b78 #3 [ffffc90000857a58] excstacksegment at ffffffff81be1f45 #4 [ffffc90000857a80] asmexcstacksegment at ffffffff81c009de #5 [ffffc90000857b08] nfslookup at ffffffffa0302322 [nfs] #6 [ffffc90000857b70] lookupslow at ffffffff813a4a5f #7 [ffffc90000857c60] walkcomponent at ffffffff813a86c4 #8 [ffffc90000857cb8] pathlookupat at ffffffff813a9553 #9 [ffffc90000857cf0] filenamelookup at ffffffff813ab86b
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix racy issue from session lookup and expire
Increment the session reference count within the lock for lookup to avoid racy issue with session expire.
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.
bnxten: Set DMA unmap len correctly for XDPREDIRECT
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifsoplockbreak
A race condition can occur in cifsoplockbreak() leading to a use-after-free of the cinode structure when unmounting:
cifsoplockbreak() cifsFileInfoput(cfile) cifsFileInfoputfinal() cifssbdeactive() [last ref, start releasing sb] killsb() killanonsuper() genericshutdownsuper() evictinodes() disposelist() evict() destroyinode() callrcu(&inode->ircu, icallback) spinlock(&cinode->openfilelock) <- OK [later] icallback() cifsfreeinode() kmemcachefree(cinode) spinunlock(&cinode->openfilelock) <- UAF cifsdoneoplockbreak(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When cifsFileInfoput() calls cifssbdeactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifsoplockbreak() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.
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.
In the Linux kernel, the following vulnerability has been resolved:
fs: dlm: fix race in lowcomms
This patch fixes a race between queuework() in dlmlowcommscommitmsg() and srcureadunlock(). The queuework() can take the final reference of a dlmmsg and so msg->idx can contain garbage which is signaled by the following warning:
[ 676.237050] ------------[ cut here ]------------ [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlmlowcommscommitmsg+0x41/0x50 [ 676.238945] Modules linked in: dlmlocktorture torture rpcsecgsskrb5 intelraplmsr intelraplcommon iTCOwdt iTCOvendorsupport qxl kvmintel drmttmhelper vmwvsockvirtiotransport kvm vmwvsockvirtiotransportcommon ttm irqbypass crc32pclmul joydev crc32cintel serioraw drmkmshelper vsock virtioscsi virtioconsole virtioballoon sndpcm drm syscopyarea sysfillrect sysimgblt sndtimer fbsysfops i2ci801 lpcich snd i2csmbus soundcore pcspkr [ 676.244227] CPU: 0 PID: 1060 Comm: locktorturewr Not tainted 5.19.0-rc3+ #1546 [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 676.246460] RIP: 0010:dlmlowcommscommitmsg+0x41/0x50 [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282 [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006 [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001 [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005 [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480 [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000 [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0 [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 676.258397] PKRU: 55555554 [ 676.258729] Call Trace: [ 676.259063] <TASK> [ 676.259354] dlmmidcommscommitmhandle+0xcc/0x110 [ 676.259964] queuebast+0x8b/0xb0 [ 676.260423] grantpendinglocks+0x166/0x1b0 [ 676.261007] unlocklock+0x75/0x90 [ 676.261469] unlocklock.isra.57+0x62/0xa0 [ 676.262009] dlmunlock+0x21e/0x330 [ 676.262457] ? locktorturestats+0x80/0x80 [dlmlocktorture] [ 676.263183] tortureunlock+0x5a/0x90 [dlmlocktorture] [ 676.263815] ? preemptcountsub+0xba/0x100 [ 676.264361] ? complete+0x1d/0x60 [ 676.264777] locktorturewriter+0xb8/0x150 [dlmlocktorture] [ 676.265555] kthread+0x10a/0x130 [ 676.266007] ? kthreadcompleteandexit+0x20/0x20 [ 676.266616] retfromfork+0x22/0x30 [ 676.267097] </TASK> [ 676.267381] irq event stamp: 9579855 [ 676.267824] hardirqs last enabled at (9579863): [<ffffffffbb14e6f8>] upconsolesem+0x58/0x60 [ 676.268896] hardirqs last disabled at (9579872): [<ffffffffbb14e6dd>] upconsolesem+0x3d/0x60 [ 676.270008] softirqs last enabled at (9579798): [<ffffffffbc200349>] dosoftirq+0x349/0x4c7 [ 676.271438] softirqs last disabled at (9579897): [<ffffffffbb0d54c0>] irqexitrcu+0xb0/0xf0 [ 676.272796] ---[ end trace 0000000000000000 ]---
I reproduced this warning with dlmlocktorture test which is currently not upstream. However this patch fix the issue by make a additional refcount between dlmlowcommsnewmsg() and dlmlowcommscommitmsg(). In case of the race the krefput() in dlmlowcommscommitmsg() will be the final put.
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix invalid accesses to cephconnectionv1info
There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use).
On 64-bit systems, con->v1.authretry overlaps with con->v2.outiter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets.
con->v1.connectseq overlaps with con->v2.connbufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec
nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.