ext4: fix OOB read when checking dotdot dir
In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: Fix VMPAT handling when fork() fails in copypagerange()
If trackpfncopy() fails, we already added the dst VMA to the maple tree. As fork() fails, we'll cleanup the maple tree, and stumble over the dst VMA for which we neither performed any reservation nor copied any page tables.
Consequently untrackpfn() will see VMPAT and try obtaining the PAT information from the page table -- which fails because the page table was not copied.
The easiest fix would be to simply clear the VMPAT flag of the dst VMA if trackpfncopy() fails. However, the whole thing is about "simply" clearing the VMPAT flag is shaky as well: if we passed trackpfncopy() and performed a reservation, but copying the page tables fails, we'll simply clear the VMPAT flag, not properly undoing the reservation ... which is also wrong.
So let's fix it properly: set the VMPAT flag only if the reservation succeeded (leaving it clear initially), and undo the reservation if anything goes wrong while copying the page tables: clearing the VMPAT flag after undoing the reservation.
Note that any copied page table entries will get zapped when the VMA will get removed later, after copypagerange() succeeded; as VMPAT is not set then, we won't try cleaning VMPAT up once more and untrackpfn() will be happy. Note that leaving these page tables in place without a reservation is not a problem, as we are aborting fork(); this process will never run.
A reproducer can trigger this usually at the first try:
https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/patfork.c
WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 getpatinfo+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:getpatinfo+0xf6/0x110 ... Call Trace: <TASK> ... untrackpfn+0x52/0x110 unmapsinglevma+0xa6/0xe0 unmapvmas+0x105/0x1f0 exitmmap+0xf6/0x460 mmput+0x4b/0x120 copyprocess+0x1bf6/0x2aa0 kernelclone+0xab/0x440 dosysclone+0x66/0x90 dosyscall64+0x95/0x180
Likely this case was missed in:
d155df53f310 ("x86/mm/pat: clear VMPAT if copyp4drange failed")
... and instead of undoing the reservation we simply cleared the VMPAT flag.
Keep the documentation of these functions in include/linux/pgtable.h, one place is more than sufficient -- we should clean that up for the other functions like trackpfnremap/untrackpfn separately.
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Fix handling of multiple calls to vhostscsisetendpoint
If vhostscsisetendpoint is called multiple times without a vhostscsiclearendpoint between them, we can hit multiple bugs found by Haoran Zhang:
1. Use-after-free when no tpgs are found:
This fixes a use after free that occurs when vhostscsisetendpoint is called more than once and calls after the first call do not find any tpgs to add to the vstpg. When vhostscsisetendpoint first finds tpgs to add to the vstpg array match=true, so we will do:
vhostvqsetbackend(vq, vstpg); ...
kfree(vs->vstpg); vs->vstpg = vstpg;
If vhostscsisetendpoint is called again and no tpgs are found match=false so we skip the vhostvqsetbackend call leaving the pointer to the vstpg we then free via:
kfree(vs->vstpg); vs->vstpg = vstpg;
If a scsi request is then sent we do:
vhostscsihandlevq -> vhostscsigetreq -> vhostvqgetbackend
which sees the vstpg we just did a kfree on.
2. Tpg dir removal hang:
This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.
The problem is that if vhostscsisetendpoint detects a tpg is already in the vs->vstpg array or if the tpg has been removed so targetdependitem fails, the undepend goto handler will do targetundependitem on all tpgs in the vstpg array dropping their refcount to 0. At this time vstpg contains both the tpgs we have added in the current vhostscsisetendpoint call as well as tpgs we added in previous calls which are also in vs->vstpg.
Later, when vhostscsiclearendpoint runs it will do targetundependitem on all the tpgs in the vs->vstpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.
3. Tpg leak:
This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhostscsisetendpoint is called multiple times but with different target names.
The bug occurs if a user has called VHOSTSCSISETENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOSTSCSISETENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vstpg array. Later when we do vhostscsiclearendpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vstpg. We will then return from the function without doing targetundependitem on the tpgs.
Because of all these bugs, it looks like being able to call vhostscsisetendpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhostscsisetendpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhostscsiclearendpoint first.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfttunnel: fix geneveopt type confusion addition
When handling multiple NFTATUNNELKEYOPTSGENEVE attributes, the parsing logic should place every geneveopt structure one by one compactly. Hence, when deciding the next geneveopt position, the pointer addition should be in units of char .
However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.
[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nfttunnelobjinit+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dumpstacklvl+0x44/0x5c [ 6.992801] printreport+0x184/0x4be [ 6.993790] kasanreport+0xc5/0x100 [ 6.994252] kasancheckrange+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nfttunnelobjinit+0x977/0xa70 [ 6.995677] nftobjinit+0x10c/0x1b0 [ 6.995891] nftablesnewobj+0x585/0x950 [ 6.996922] nfnetlinkrcvbatch+0xdf9/0x1020 [ 6.998997] nfnetlinkrcv+0x1df/0x220 [ 6.999537] netlinkunicast+0x395/0x530 [ 7.000771] netlinksendmsg+0x3d0/0x6d0 [ 7.001462] socksendmsg+0x99/0xa0 [ 7.001707] syssendmsg+0x409/0x450 [ 7.002391] syssendmsg+0xfd/0x170 [ 7.003145] syssendmsg+0xea/0x170 [ 7.004359] dosyscall64+0x5e/0x90 [ 7.005817] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIGRAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8
Fix this bug with correct pointer addition and conversion in parse and dump code.
In the Linux kernel, the following vulnerability has been resolved:
net: fix geneveopt length integer overflow
struct geneveopt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes.
However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to fake a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read.
One example crash log is like below:
[ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nlaput+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] <TASK> [ 3.908048] dumpstacklvl+0x44/0x5c [ 3.908258] printreport+0x184/0x4be [ 3.909151] kasanreport+0xc5/0x100 [ 3.909539] kasancheckrange+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nlaput+0xa9/0xe0 [ 3.910147] tunnelkeydump+0x945/0xba0 [ 3.911536] tcfactiondump1+0x1c1/0x340 [ 3.912436] tcfactiondump+0x101/0x180 [ 3.912689] tcfextsdump+0x164/0x1e0 [ 3.912905] fwdump+0x18b/0x2d0 [ 3.913483] tcffillnode+0x2ee/0x460 [ 3.914778] tfilternotify+0xf4/0x180 [ 3.915208] tcnewtfilter+0xd51/0x10d0 [ 3.918615] rtnetlinkrcvmsg+0x4a2/0x560 [ 3.919118] netlinkrcvskb+0xcd/0x200 [ 3.919787] netlinkunicast+0x395/0x530 [ 3.921032] netlinksendmsg+0x3d0/0x6d0 [ 3.921987] socksendmsg+0x99/0xa0 [ 3.922220] syssendto+0x1b7/0x240 [ 3.922682] x64syssendto+0x72/0x90 [ 3.922906] dosyscall64+0x5e/0x90 [ 3.923814] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIGRAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8
Fix these issues by enforing correct length condition in related policies.
In the Linux kernel, the following vulnerability has been resolved:
iptunnel: adapt iptunnelxmitstats() to NETDEVPCPUSTATDSTATS
Blamed commits forgot that vxlan/geneve use udptunnel[6]xmitskb() which call iptunnelxmitstats().
iptunnelxmitstats() was assuming tunnels were only using NETDEVPCPUSTATTSTATS.
@syncp offset in pcpuswnetstats and pcpudstats is different.
32bit kernels would either have corruptions or freezes if the syncp sequence was overwritten.
This patch also moves pcpustattype closer to dev->{t,d}stats to avoid a potential cache line miss since iptunnelxmitstats() needs to read it.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Tear down vGIC on failed vCPU creation
If kvmarchvcpucreate() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.
Add the missing cleanup to kvmarchvcpucreate(), ensuring that the vGIC vCPU structures are destroyed on error.
btrfs: harden blockgroup::bglist against listdel() races
In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue
When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash.
Add flag 'ioadminresetsync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.
In the Linux kernel, the following vulnerability has been resolved:
perf/aux: Fix page UAF in maprange()
maprange() reads rb->auxpages[], rb->auxnrpages and rb->auxpgoff via perfmmaptopage() while holding only event->mmapmutex. Those fields are serialized by rb->auxmutex, and mmapmutex is per event.
Thus, two events sharing one rb via PERFEVENTIOCSETOUTPUT can race rballocaux() with maprange(), leading to a page-UAF scenario as follows:
CPU 0 CPU 1 ===== ===== rballocaux() maprange() [1]: allocate rb->auxpages[0] [2]: rb->auxnrpages++ [3]: perfmmaptopage() returns rb->auxpages[0] [4]: map it as VMPFNMAP [5]: rb->auxpgoff = 1
munmap the page [6]: free rb->auxpages[0]
Pages mapped as VMPFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame.
Fix this by taking rb->auxmutex across the page walk in maprange().
In the Linux kernel, the following vulnerability has been resolved:
fprobe: Fix unregisterfprobe() to wait for RCU grace period
Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer") changed fprobe to register struct fprobe to an rcu-hlist, but it forgot to wait for RCU GP. Thus there can be use-after-free if the fprobe is released right after unregistering. This can be happened on fprobe event and sample module code.
To fix this issue, add synchronizercu() in unregisterfprobe().
Note that BPF is OK because fprobe is used as a part of bpfkprobemultilink. This unregisters its fprobe in bpfkprobemultilinkrelease() and it is deallocated via bpfkprobemultilinkdealloc(), which is invoked from bpflinkdeferdeallocrcugp() RCU callback.
For BPF, this also introduced unregisterfprobeasync() which does NOT wait for RCU grace priod.
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix the locking used by afsgetlink()
The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are a number of problems:
(1) It doesn't do any locking around afsreadsingle() to prevent races between multiple ->getlink() calls, thereby allowing the possibility of leaks.
(2) It doesn't use RCU barriering when accessing the buffer pointers during RCU pathwalk.
(3) It can race with another thread updating the contents of the symlink if a third party updated it on the server.
Fix this by the following means:
(0) Move symlink handling into its own file as this makes it more complicated.
(1) Take the validatelock around afsreadsingle() to prevent races between multiple ->getlink() calls.
(2) Keep a separate copy of the symlink contents with an rcuhead. This is always going to be a lot smaller than a page, so it can be kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk.
(3) Split the symlink read and write-to-cache routines in afs from those for directories.
(4) Discard the I/O buffer as soon as the write-to-cache completes as this is a full page (plus a folioqueue).
(5) If there's no cache, discard the I/O buffer immediately after reading and copying if there is no cache.
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Fix accessing freed irq affinityhint
In stmmacrequestirqmultimsi(), a pointer to the stack variable cpumask is passed to irqsetaffinityhint(). This value is stored in irqdesc->affinityhint, but once stmmacrequestirqmultimsi() returns, the pointer becomes dangling.
The affinityhint is exposed via procfs with SIRUGO permissions, allowing any unprivileged process to read it. Accessing this stale pointer can lead to:
- a kernel oops or panic if the referenced memory has been released and unmapped, or - leakage of kernel data into userspace if the memory is re-used for other purposes.
All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are affected.
In the Linux kernel, the following vulnerability has been resolved:
net: decrease cached dst counters in dstrelease
Upstream fix ac888d58869b ("net: do not delay dstentriesadd() in dstrelease()") moved decrementing the dst count from dstdestroy to dstrelease to avoid accessing already freed data in case of netns dismantle. However in case CONFIGDSTCACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:
Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpucounteraddbatch+0x3c/0x160 (P) dstrelease+0xec/0x108 dstcachedestroy+0x68/0xd8 dstdestroy+0x13c/0x168 dstdestroyrcu+0x1c/0xb0 rcudobatch+0x18c/0x7d0 rcucore+0x174/0x378 rcucoresi+0x18/0x30
Fix this by invalidating the cache, and thus decrementing cached dst counters, in dstrelease too.
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhcihcd: AMD-Vi: Event logged [IOPAGEFAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhcihcd: AMD-Vi: Event logged [IOPAGEFAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhcihcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042144] xhcihcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042266] xhcihcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098132] xhcihcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098256] xhcihcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhcihcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhcihcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVEROK cmdage=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 physseg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: Avoid queue->stopped races and set/read that value under lock
There are several readers of queue->stopped that check the value under lock, but fuseuringcommitfetch() did not and actually the value was not set under the lock in fuseuringabortendrequests() either. Especially in fuseuringcommitfetch it is important to check under a lock, because due to races 'struct fusereq' might be freed with fuserequestend, but another thread/cpu might already do teardown work.
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: Avoid use-after-free in fuseuringasyncstopqueues
fuseuringasyncstopqueues() might run when the last reference on ring->queuerefs was already dropped.
In order to avoid an early destruction a reference on struct fuseconn is now taken before starting fuseuringasyncstopqueues() and that reference is only released when that delayed work queue terminates.
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: make a fusereq on SQE commit only findable after memcpy
Bad userspace might try to trick us and send commit SQEs request unique / commit-id of requests that are not even send to fuse-server (iouringcmddone() not called) yet.
fuseuringcommitfetch() ends the fuse request when the ring entry has a wrong state, but that could have caused a use-after-free with the memcpy operations in fuseuringsendintask(). In order to avoid such races the call of fuseuringaddtopq() is moved after the copy operations and just before completing the io-uring request - malicious userspace cannot find the request anymore until all prepration work in fuse-client/kernel is completed.
This also moves fuseuringaddtopq() a bit up in the code to avoid a forward declaration. Also not with a preparation commit, to make it easier to back port to older kernels.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate zero numsubauth before subauth is accessed
Access psid->subauth[psid->numsubauth - 1] without checking if numsubauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure numsubauth != 0 before subauth is accessed.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbdsessionsderegister()
In multichannel mode, UAF issue can occur in sessionderegister when the second channel sets up a session through the connection of the first channel. session that is freed through the global session table can be accessed again through ->sessions of connection.
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix slab-out-of-bounds read in eaget()
During the "sizecheck" label in eaget(), the code checks if the extended attribute list (xattr) size matches easize. If not, it logs "eaget: invalid extended attribute" and calls printhexdump().
Here, EALISTSIZE(eabuf->xattr) returns 4110417968, which exceeds INTMAX (2,147,483,647). Then easize is clamped:
int size = clampt(int, easize, 0, EALISTSIZE(eabuf->xattr));
Although clampt aims to bound easize between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328).
The "size" is then passed to printhexdump() (called "len" in printhexdump()), it is passed as type sizet (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hexdumptobuffer(). In printhexdump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hexdumptobuffer() on each iteration:
for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize;
hexdumptobuffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii);
... }
The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hexdumptobuffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hexdumptobuffer() in the following for loop:
for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... }
To fix this we should validate "EALISTSIZE(eabuf->xattr)" before it is utilised.
HSI: ssiprotocol: Fix use after free vulnerability in ssiprotocol Driver Due to Race Condition
drm/vkms: Fix use after free and double free on init error
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix use-after-free in printgraphfunctionflags during tracer switching
Kairui reported a UAF issue in printgraphfunctionflags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutexunlock(&tracetypeslock)' in sstart(), and executing the following script:
$ echo functiongraph > currenttracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > currenttracer
The root cause lies in the two calls to printgraphfunctionflags within printtraceline during each sshow():
One through 'iter->trace->printline()'; Another through 'event->funcs->trace()', which is hidden in printtracefmt() before printtraceline returns.
Tracer switching only updates the former, while the latter continues to use the printline function of the old tracer, which in the script above is printgraphfunctionflags.
Moreover, when switching from the 'functiongraph' tracer to the 'timerlat' tracer, sstart only calls graphtraceclose of the 'functiongraph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'.
To fix this issue, set 'iter->private' to NULL immediately after freeing it in graphtraceclose(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers.
[1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix session use-after-free in multichannel connection
There is a race condition between session setup and ksmbdsessionsderegister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it.
In the Linux kernel, the following vulnerability has been resolved:
virt: sev-guest: Explicitly leak pages in unknown state
When setmemory{encrypted,decrypted}() fail, the user cannot know at which point the function failed, meaning that the pages are left in an unknown state from the point of view of the caller.
Since the pages may be left in an unencrypted state, they are not suitable for general use, and cannot be returned safely to the buddy allocator. Avoid the issue by never freeing the pages, and then do the proper accounting by calling snpleakpages().
In the Linux kernel, the following vulnerability has been resolved:
tracing: Verify event formats that have "%p.."
The trace event verifier checks the formats of trace events to make sure that they do not point at memory that is not in the trace event itself or in data that will never be freed. If an event references data that was allocated when the event triggered and that same data is freed before the event is read, then the kernel can crash by reading freed memory.
The verifier runs at boot up (or module load) and scans the print formats of the events and checks their arguments to make sure that dereferenced pointers are safe. If the format uses "%p.." the verifier will ignore it, and that could be dangerous. Cover this case as well.
Also add to the sample code a use case of "%pbl".
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
In the Linux kernel, the following vulnerability has been resolved:
rxrpc: Fix irq-disabled in localbhenable()
The rxrpcassessMTUsize() function calls down into the IP layer to find out the MTU size for a route. When accepting an incoming call, this is called from rxrpcnewincomingcall() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses localbhenable() which, config dependent, throws a warning if IRQs are enabled:
WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 localbhenableip+0x43/0xd0 ... RIP: 0010:localbhenableip+0x43/0xd0 ... Call Trace: <TASK> rtcacheroute+0x7e/0xa0 rtsetnexthop.isra.0+0x3b3/0x3f0 mkrouteoutput+0x43a/0x460 iprouteoutputkeyhash+0xf7/0x140 iprouteoutputflow+0x1b/0x90 rxrpcassessMTUsize.isra.0+0x2a0/0x590 rxrpcnewincomingpeer+0x46/0x120 rxrpcallocincomingcall+0x1b1/0x400 rxrpcnewincomingcall+0x1da/0x5e0 rxrpcinputpacket+0x827/0x900 rxrpciothread+0x403/0xb60 kthread+0x2f7/0x310 retfromfork+0x2a/0x230 retfromforkasm+0x1a/0x30 ... hardirqs last enabled at (23): rawspinunlockirq+0x24/0x50 hardirqs last disabled at (24): rawreadlockirq+0x17/0x70 softirqs last enabled at (0): copyprocess+0xc61/0x2730 softirqs last disabled at (25): rtadduncachedlist+0x3c/0x90
Fix this by moving the call to rxrpcassessMTUsize() out of rxrpcinitpeer() and further up the stack where it can be done without interrupts disabled.
It shouldn't be a problem for rxrpcnewincomingcall() to do it after the locks are dropped as pmtud is going to be performed by the I/O thread - and we're in the I/O thread at this point.
In the Linux kernel, the following vulnerability has been resolved:
tee: optee: prevent use-after-free when the client exits before the supplicant
Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request.
If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free.
Serialise access to the request with supp->mutex:
Hold supp->mutex in opteesupprecv() and opteesuppsend() while looking up and touching the request. Let opteesuppthrdreq() notice that the client has terminated and signal opteesuppsend() accordingly.
With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.