In the Linux kernel, the following vulnerability has been resolved:
crypto: caam - use printhexdumpdevel to guard key hex dumps
Use printhexdumpdevel() for dumping sensitive key material in setkey() to avoid leaking secrets at runtime when CONFIGDYNAMICDEBUG is enabled.
In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: CGX: add bounds check to cgxspeedmbps index
cgxspeedmbps has 13 elements but RESPLINKSTATSPEED can yield values 0-15. If it returns a value >= 13, this causes an out-of-bounds array access. Add a bounds check and default to speed 0 if the index is out of range.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix race between dump and ipsetlist resize
The release path of ipsetdumpdo() and ipsetdumpdone() read inst->ipsetlist via ipsetrefnetlink(), a plain rcudereferenceraw() of the array pointer. These run from netlinkrecvmsg() without the nfnl mutex and without an RCU read-side critical section.
A concurrent ipsetcreate() can grow the array: it publishes the new array, calls synchronizenet() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronizenet() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free.
The dumped set itself stays pinned via set->refnetlink, so only the array load needs protecting. Take rcureadlock() around it, matching ipsetgetbyname() and ipsetputbyindex().
BUG: KASAN: slab-use-after-free in ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasanreport (mm/kasan/report.c:595) ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1697) netlinkdump (net/netlink/afnetlink.c:2325) netlinkrecvmsg (net/netlink/afnetlink.c:1976) sockrecvmsg (net/socket.c:1159) sysrecvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ipsetdumpdo (net/netfilter/ipset/ipsetcore.c:1698) Kernel panic - not syncing: Fatal exception
fuse: reject fusenotify() pagecache ops on directories
In the Linux kernel, the following vulnerability has been resolved:
nvmem: core: fix use-after-free bugs in error paths
Fix several instances of error paths in which we call nvmemdeviceput() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.
In the Linux kernel, the following vulnerability has been resolved:
tun: free page on buildskb failure in tunxdpone()
When buildskb() fails in tunxdpone(), the function sets ret to -ENOMEM and jumps to the out label, which returns without freeing the page that vhostnetbuildxdp() allocated for the frame. As with the short-frame rejection path, tunsendmsg() discards the per-buffer error and still returns totallen, so vhosttxbatch() takes the success path and never frees the page. Each buildskb() failure in a batch leaks one page-frag chunk.
Free the page before taking the error path, matching the putpage() the other error exits of tunxdpone() already perform.
In the Linux kernel, the following vulnerability has been resolved:
tap: free page on error paths in tapgetuserxdp()
tapgetuserxdp() rejects a frame shorter than ETHHLEN with -EINVAL, and returns -ENOMEM when buildskb() fails. Both paths jump to the err label without freeing the page that vhostnetbuildxdp() allocated for the frame. tapsendmsg() discards the per-buffer return value and always returns 0, so vhosttxbatch() takes the success path and never frees the page; each rejected frame in a batch leaks one page-frag chunk.
Free the page on both error paths, before the skb is built. This is the tap counterpart of the same leak in tunxdpone().
In the Linux kernel, the following vulnerability has been resolved:
ASoC: soc-core: flush delayed work before removing DAIs and widgets
When a sound card is unbound while a PCM stream is open, a use-after-free can occur in sndsocdapmstreamevent(), called from the closedelayedwork workqueue handler.
During unbind, sndsocunbindcard() flushes delayed work and then calls soccleanupcardresources(). Inside cleanup, sndcarddisconnectsync() releases all PCM file descriptors, and the resulting PCM close path can call sndsocdapmstreamstop() which schedules new delayed work with a pmdowntime timer delay. Since this happens after the flush in sndsocunbindcard(), the new work is not caught. socremovelinkcomponents() then frees DAPM widgets before this work fires, leading to the use-after-free.
The existing flush in socfreepcmruntime() also cannot help as it runs after socremovelinkcomponents() has already freed the widgets.
Add a flush in soccleanupcardresources() after sndcarddisconnectsync() (after which no new PCM closes can schedule further delayed work) and before socremovelinkdais() and socremovelinkcomponents() (which tear down the structures the delayed work accesses).
fuse: reject oversized dirents in page cache
In the Linux kernel, the following vulnerability has been resolved:
media: mc, v4l2: serialize REINIT and REQBUFS with reqqueuemutex
MEDIAREQUESTIOCREINIT can run concurrently with VIDIOCREQBUFS(0) queue teardown paths. This can race request object cleanup against vb2 queue cancellation and lead to use-after-free reports.
We already serialize request queueing against STREAMON/OFF with reqqueuemutex. Extend that serialization to REQBUFS, and also take the same mutex in mediarequestioctlreinit() so REINIT is in the same exclusion domain.
This keeps request cleanup and queue cancellation from running in parallel for request-capable devices.
In the Linux kernel, the following vulnerability has been resolved:
net: annotate data-races around sk->sk{dataready,writespace}
skmsg (and probably other layers) are changing these pointers while other cpus might read them concurrently.
Add corresponding READONCE()/WRITEONCE() annotations for UDP, TCP and AFUNIX.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/64s/slb: Fix SLB multihit issue during SLB preload
On systems using the hash MMU, there is a software SLB preload cache that mirrors the entries loaded into the hardware SLB buffer. This preload cache is subject to periodic eviction — typically after every 256 context switches — to remove old entry.
To optimize performance, the kernel skips switchmmucontext() in switchmmirqsoff() when the prev and next mmstruct are the same. However, on hash MMU systems, this can lead to inconsistencies between the hardware SLB and the software preload cache.
If an SLB entry for a process is evicted from the software cache on one CPU, and the same process later runs on another CPU without executing switchmmucontext(), the hardware SLB may retain stale entries. If the kernel then attempts to reload that entry, it can trigger an SLB multi-hit error.
The following timeline shows how stale SLB entries are created and can cause a multi-hit error when a process moves between CPUs without a MMU context switch.
CPU 0 CPU 1 ----- ----- Process P exec swapper/1 loadelfbinary beginnewexc activatemm switchmmirqsoff switchmmucontext switchslb / This invalidates all the entries in the HW and setup the new HW SLB entries as per the preload cache. / contextswitch schedmigratetask migrates process P to cpu-1
Process swapper/0 context switch (to process P) (uses mmstruct of Process P) switchmmirqsoff() switchslb loadslb++ / loadslb becomes 0 here and we evict an entry from the preload cache with preloadage(). We still keep HW SLB and preload cache in sync, that is because all HW SLB entries anyways gets evicted in switchslb during SLBIA. We then only add those entries back in HW SLB, which are currently present in preloadcache (after eviction). / loadelfbinary continues... setupnewexec() slbsetupnewexec()
schedswitch event schedmigratetask migrates process P to cpu-0
contextswitch from swapper/0 to Process P switchmmirqsoff() / Since both prev and next mm struct are same we don't call switchmmucontext(). This will cause the HW SLB and SW preload cache to go out of sync in preloadnewslbcontext. Because there was an SLB entry which was evicted from both HW and preload cache on cpu-1. Now later in preloadnewslbcontext(), when we will try to add the same preload entry again, we will add this to the SW preload cache and then will add it to the HW SLB. Since on cpu-0 this entry was never invalidated, hence adding this entry to the HW SLB will cause a SLB multi-hit error. / loadelfbinary cont ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix buffer overflow in liotargetnaclinfoshow()
The function liotargetnaclinfoshow() uses sprintf() in a loop to print details for every iSCSI connection in a session without checking for the buffer length. With enough iSCSI connections it's possible to overflow the buffer provided by configfs and corrupt the memory.
This patch replaces sprintf() with sysfsemitat() that checks for buffer boundries.
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix possible descptr out-of-bounds accesses
Sanitize possible descptr out-of-bounds accesses in sesenclosuredataprocess().
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix deadloop issue on reading tracepipe
Soft lockup occurs when reading file 'tracepipe':
watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ringbufferemptycpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: findnextentry+0x1a8/0x4b0 ? peeknextentry+0x250/0x250 ? downwrite+0xa5/0x120 ? downwritekillable+0x130/0x130 tracefindnextentryinc+0x3b/0x1d0 tracingreadpipe+0x423/0xae0 ? tracingsplicereadpipe+0xcb0/0xcb0 vfsread+0x16b/0x490 ksysread+0x105/0x210 ? ia32syspwrite64+0x200/0x200 ? switchfpureturn+0x108/0x220 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x61/0xc6
Through the vmcore, I found it's because in tracingreadpipe(), ringbufferemptycpu() found some buffer is not empty but then it cannot read anything due to "rbnumofentries() == 0" always true, Then it infinitely loop the procedure due to user buffer not been filled, see following code path:
tracingreadpipe() { ... ... waitagain: tracingwaitpipe() // 1. find non-empty buffer here tracefindnextentryinc() // 2. loop here try to find an entry findnextentry() ringbufferemptycpu(); // 3. find non-empty buffer peeknextentry() // 4. but peek always return NULL ringbufferpeek() rbbufferpeek() rbgetreaderpage() // 5. because rbnumofentries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! }
By some analyzing, I found that when resetting ringbuffer, the 'entries' of its pages are not all cleared (see rbresetcpu()). Then when reducing the ringbuffer, and if some reduced pages exist dirty 'entries' data, they will be added into 'cpubuffer->overrun' (see rbremovepages()), which cause wrong 'overrun' count and eventually cause the deadloop issue.
To fix it, we need to clear every pages in rbresetcpu().
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a null-ptr-deref in tipctopsrvaccept
syzbot found a crash in tipctopsrvaccept:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipcrcv tipctopsrvaccept RIP: 0010:kernelaccept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipctopsrvaccept+0x197/0x280 net/tipc/topsrv.c:460 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306
It was caused by srv->listener that might be set to null by tipctopsrvstop() in net .exit whereas it's still used in tipctopsrvaccept() worker.
srv->listener is protected by srv->idrlock in tipctopsrvstop(), so add a check for srv->listener under srv->idrlock in tipctopsrvaccept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipctopsrvaccept(), move sockrelease() after tipctopsrvworkstop() where it's waiting until the tipctopsrvaccept worker to be done.
Note that skcallbacklock is used to protect sk->skuserdata instead of srv->listener, and it should check srv in tipctopsrvlistenerdataready() instead. This also ensures that no more tipctopsrvaccept worker will be started after tipcconnclose() is called in tipctopsrvstop() where it sets sk->skuserdata to null.
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmffwallocrequest()
This patch fixes a shift-out-of-bounds in brcmfmac that occurs in BIT(chiprev) when a 'chiprev' provided by the device is too large. It should also not be equal to or greater than BITSPERTYPE(u32) as we do bitwise AND with a u32 variable and BIT(chiprev). The patch adds a check that makes the function return NULL if that is the case. Note that the NULL case is later handled by the bus-specific caller, brcmfusbprobecb() or brcmfusbresetresume(), for example.
Found by a modified version of syzkaller.
UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c shift exponent 151055786 is too large for 64-bit type 'long unsigned int' CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usbhubwq hubevent Call Trace: dumpstacklvl+0x57/0x7d ubsanepilogue+0x5/0x40 ubsanhandleshiftoutofbounds.cold+0x53/0xdb ? lockchaincount+0x20/0x20 brcmffwallocrequest.cold+0x19/0x3ea ? brcmffwgetfirmwares+0x250/0x250 ? brcmfusbioctlrespwait+0x1a7/0x1f0 brcmfusbgetfwname+0x114/0x1a0 ? brcmfusbresetresume+0x120/0x120 ? number+0x6c4/0x9a0 brcmfcprocessclmblob+0x168/0x590 ? putdec+0x90/0x90 ? enableptrkeyworkfn+0x20/0x20 ? brcmfcommonpdremove+0x50/0x50 ? rcureadlockschedheld+0xa1/0xd0 brcmfcpreinitdcmds+0x673/0xc40 ? brcmfcsetjoinprefdefault+0x100/0x100 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockacquire+0x19d/0x4e0 ? findheldlock+0x2d/0x110 ? brcmfusbdeq+0x1cc/0x260 ? markheldlocks+0x9f/0xe0 ? lockdephardirqsonprepare+0x273/0x3e0 ? rawspinunlockirqrestore+0x47/0x50 ? tracehardirqson+0x1c/0x120 ? brcmfusbdeq+0x1a7/0x260 ? brcmfusbrxfillall+0x5a/0xf0 brcmfattach+0x246/0xd40 ? wiphynewnm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmfusbprobe+0x12de/0x1690 ? brcmfusbdevqinit.constprop.0+0x470/0x470 usbprobeinterface+0x25f/0x710 reallyprobe+0x1be/0xa90 driverprobedevice+0x2ab/0x460 ? usbmatchid.part.0+0x88/0xc0 driverprobedevice+0x49/0x120 deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? mutexunlockslowpath+0xe7/0x660 ? fwdevlinklinktosuppliers+0x550/0x550 usbsetconfiguration+0x984/0x1770 ? kernfscreatelink+0x175/0x230 usbgenericdriverprobe+0x69/0x90 usbprobedevice+0x9c/0x220 reallyprobe+0x1be/0xa90 driverprobedevice+0x2ab/0x460 driverprobedevice+0x49/0x120 deviceattachdriver+0x18a/0x250 ? driverallowsasyncprobing+0x120/0x120 busforeachdrv+0x123/0x1a0 ? busrescandevices+0x20/0x20 ? lockdephardirqsonprepare+0x273/0x3e0 ? tracehardirqson+0x1c/0x120 deviceattach+0x207/0x330 ? devicebinddriver+0xb0/0xb0 ? kobjectueventenv+0x230/0x12c0 busprobedevice+0x1a2/0x260 deviceadd+0xa61/0x1ce0 ? fwdevlinklinktosuppliers+0x550/0x550 usbnewdevice.cold+0x463/0xf66 ? hubdisconnect+0x400/0x400 ? rawspinunlockirq+0x24/0x30 hubevent+0x10d5/0x3330 ? hubportdebounce+0x280/0x280 ? lockacquire+0x1671/0x5790 ? wqcalcnodecpumask+0x170/0x2a0 ? lockrelease+0x640/0x640 ? rcureadlockschedheld+0xa1/0xd0 ? rcureadlockbhheld+0xb0/0xb0 ? lockdephardirqsonprepare+0x273/0x3e0 processonework+0x873/0x13e0 ? lockrelease+0x640/0x640 ? pwqdecnrinflight+0x320/0x320 ? rwlockbug.part.0+0x90/0x90 workerthread+0x8b/0xd10 ? kthreadparkme+0xd9/0x1d0 ? pr ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
media: si470x: Fix use-after-free in si470xintincallback()
syzbot reported use-after-free in si470xintincallback() [1]. This indicates that urb->context, which contains struct si470xdevice object, is freed when si470xintincallback() is called.
The cause of this issue is that si470xintincallback() is called for freed urb.
si470xusbdriverprobe() calls si470xstartusb(), which then calls usbsubmiturb() and si470xstart(). If si470xstartusb() fails, si470xusbdriverprobe() doesn't kill urb, but it just frees struct si470xdevice object, as depicted below:
si470xusbdriverprobe() ... si470xstartusb() ... usbsubmiturb() retval = si470xstart() return retval if (retval < 0) free struct si470xdevice object, but don't kill urb
This patch fixes this issue by killing urb when si470xstartusb() fails and urb is submitted. If si470xstartusb() fails and urb is not submitted, i.e. submitting usb fails, it just frees struct si470xdevice object.
In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix possible data races in gfs2showoptions()
Some fields such as gtlogdsecs of the struct gfs2tune are accessed without holding the lock gtspin in gfs2showoptions():
val = sdp->sdtune.gtlogdsecs; if (val != 30) seqprintf(s, ",commit=%d", val);
And thus can cause data races when gfs2showoptions() and other functions such as gfs2reconfigure() are concurrently executed:
spinlock(>->gtspin); gt->gtlogdsecs = newargs->arcommit;
To fix these possible data races, the lock sdp->sdtune.gtspin is acquired before accessing the fields of gfs2tune and released after these accesses.
Further changes by Andreas:
- Don't hold the spin lock over the seqprintf operations.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: conntrack: Avoid nfcthelperhash uses after free
If nfconntrackinitstart() fails (for example due to a registernfconntrackbpf() failure), the nfconntrackhelperfini() clean-up path frees the nfcthelperhash map.
When built with NFCONNTRACK=y, further netfilter modules (e.g: netfilterconntrackftp) can still be loaded and call nfconntrackhelpersregister(), independently of whether nfconntrack initialized correctly. This accesses the nfcthelperhash dangling pointer and causes a uaf, possibly leading to random memory corruption.
This patch guards nfconntrackhelperregister() from accessing a freed or uninitialized nfcthelperhash pointer and fixes possible uses-after-free when loading a conntrack module.
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix invalid free of JFSIP(ipimap)->iimap in diUnmount
syzbot found an invalid-free in diUnmount:
BUG: KASAN: double-free in slabfree mm/slub.c:3661 [inline] BUG: KASAN: double-free in kmemcachefree+0x71/0x110 mm/slub.c:3674 Free of addr ffff88806f410000 by task syz-executor131/3632
CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 printaddressdescription+0x74/0x340 mm/kasan/report.c:284 printreport+0x107/0x1f0 mm/kasan/report.c:395 kasanreportinvalidfree+0xac/0xd0 mm/kasan/report.c:460 kasanslabfree+0xfb/0x120 kasanslabfree include/linux/kasan.h:177 [inline] slabfreehook mm/slub.c:1724 [inline] slabfreefreelisthook+0x12e/0x1a0 mm/slub.c:1750 slabfree mm/slub.c:3661 [inline] kmemcachefree+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfsimap.c:195 jfsumount+0x108/0x370 fs/jfs/jfsumount.c:63 jfsputsuper+0x86/0x190 fs/jfs/super.c:194 genericshutdownsuper+0x130/0x310 fs/super.c:492 killblocksuper+0x79/0xd0 fs/super.c:1428 deactivatelockedsuper+0xa7/0xf0 fs/super.c:332 cleanupmnt+0x494/0x520 fs/namespace.c:1186 taskworkrun+0x243/0x300 kernel/taskwork.c:179 exittaskwork include/linux/taskwork.h:38 [inline] doexit+0x664/0x2070 kernel/exit.c:820 dogroupexit+0x1fd/0x2b0 kernel/exit.c:950 dosysexitgroup kernel/exit.c:961 [inline] sesysexitgroup kernel/exit.c:959 [inline] x64sysexitgroup+0x3b/0x40 kernel/exit.c:959 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd [...]
JFSIP(ipimap)->iimap is not setting to NULL after free in diUnmount. If jfsremount() free JFSIP(ipimap)->iimap but then failed at diMount(). JFSIP(ipimap)->iimap will be freed once again. Fix this problem by setting JFSIP(ipimap)->iimap to NULL after free.
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential UAF of struct nilfsscinfo in nilfssegctorthread()
The finalization of nilfssegctorthread() can race with nilfssegctorkillthread() which terminates that thread, potentially causing a use-after-free BUG as KASAN detected.
At the end of nilfssegctorthread(), it assigns NULL to "sctask" member of "struct nilfsscinfo" to indicate the thread has finished, and then notifies nilfssegctorkillthread() of this using waitqueue "scwaittask" on the struct nilfsscinfo.
However, here, immediately after the NULL assignment to "sctask", it is possible that nilfssegctorkillthread() will detect it and return to continue the deallocation, freeing the nilfsscinfo structure before the thread does the notification.
This fixes the issue by protecting the NULL assignment to "sctask" and its notification, with spinlock "scstatelock" of the struct nilfsscinfo. Since nilfssegctorkillthread() does a final check to see if "sctask" is NULL with "scstatelock" locked, this can eliminate the race.
In the Linux kernel, the following vulnerability has been resolved:
nfsd: clean up potential nfsdfile refcount leaks in COPY codepath
There are two different flavors of the nfsd4copy struct. One is embedded in the compound and is used directly in synchronous copies. The other is dynamically allocated, refcounted and tracked in the client struture. For the embedded one, the cleanup just involves releasing any nfsdfiles held on its behalf. For the async one, the cleanup is a bit more involved, and we need to dequeue it from lists, unhash it, etc.
There is at least one potential refcount leak in this code now. If the kthreadcreate call fails, then both the src and dst nfsdfiles in the original nfsd4copy object are leaked.
The cleanup in this codepath is also sort of weird. In the async copy case, we'll have up to four nfsdfile references (src and dst for both flavors of copy structure). They are both put at the end of nfsd4doasynccopy, even though the ones held on behalf of the embedded one outlive that structure.
Change it so that we always clean up the nfsdfile refs held by the embedded copy structure before nfsd4copy returns. Rework cleanupasynccopy to handle both inter and intra copies. Eliminate nfsd4cleanupintrassc since it now becomes a no-op.
In the Linux kernel, the following vulnerability has been resolved:
dm integrity: call kmemcachedestroy() in dmintegrityinit() error path
Otherwise the journaliocache will leak if dmregistertarget() fails.
In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Sync IRQ works before buffer destruction
If something was written to the buffer just before destruction, it may be possible (maybe not in a real system, but it did happen in ARCH=um with time-travel) to destroy the ringbuffer before the IRQ work ran, leading this KASAN report (or a crash without KASAN):
BUG: KASAN: slab-use-after-free in irqworkrunlist+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0
CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] showstack+0x25e/0x282 [<60c609e0>] dumpstacklvl+0x96/0xfd [<60c50d4c>] printreport+0x1a7/0x5a8 [<603078d3>] kasanreport+0xc1/0xe9 [<60308950>] asanreportload8noabort+0x1b/0x1d [<60232844>] irqworkrunlist+0x11a/0x13a [<602328b4>] irqworktick+0x24/0x34 [<6017f9dc>] updateprocesstimes+0x162/0x196 [<6019f335>] tickschedhandle+0x1a4/0x1c3 [<6019fd9e>] tickschedtimer+0x79/0x10c [<601812b9>] hrtimerrunqueues.constprop.0+0x425/0x695 [<60182913>] hrtimerinterrupt+0x16c/0x2c4 [<600486a3>] umtimer+0x164/0x183 [...]
Allocated by task 411: savestacktrace+0x99/0xb5 stacktracesave+0x81/0x9b kasansavestack+0x2d/0x54 kasansettrack+0x34/0x3e kasansaveallocinfo+0x25/0x28 kasankmalloc+0x8b/0x97 kasankmalloc+0x10/0x12 kmalloc+0xb2/0xe8 loadelfphdrs+0xee/0x182 [...]
The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00)
Add the appropriate irqworksync() so the work finishes before the buffers are destroyed.
Prior to the commit in the Fixes tag below, there was only a single global IRQ work, so this issue didn't exist.
In the Linux kernel, the following vulnerability has been resolved:
binfmtmisc: fix shift-out-of-bounds in checkspecialflags
UBSAN reported a shift-out-of-bounds warning:
left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x8d/0xcf lib/dumpstack.c:106 ubsanepilogue+0xa/0x44 lib/ubsan.c:151 ubsanhandleshiftoutofbounds+0x1e7/0x208 lib/ubsan.c:322 checkspecialflags fs/binfmtmisc.c:241 [inline] createentry fs/binfmtmisc.c:456 [inline] bmregisterwrite+0x9d3/0xa20 fs/binfmtmisc.c:654 vfswrite+0x11e/0x580 fs/readwrite.c:582 ksyswrite+0xcf/0x120 fs/readwrite.c:637 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x34/0x80 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x4194e1
Since the type of Node's flags is unsigned long, we should define these macros with same type too.
In the Linux kernel, the following vulnerability has been resolved:
dm cache: Fix UAF in destroy()
Dmcache also has the same UAF problem when dmresume() and dmdestroy() are concurrent.
Therefore, cancelling timer again in destroy().
In the Linux kernel, the following vulnerability has been resolved:
ext2: Check block size validity during mount
Check that log of block size stored in the superblock has sensible value. Otherwise the shift computing the block size can overflow leading to undefined behavior.
In the Linux kernel, the following vulnerability has been resolved:
tracing/histograms: Add histograms to histvars if they have referenced variables
Hist triggers can have referenced variables without having direct variables fields. This can be the case if referenced variables are added for trigger actions. In this case the newly added references will not have field variables. Not taking such referenced variables into consideration can result in a bug where it would be possible to remove hist trigger with variables being refenced. This will result in a bug that is easily reproducable like so
$ cd /sys/kernel/tracing $ echo 'syntheticsysenter char[] comm; long id' >> syntheticevents $ echo 'hist:keys=commonpid.execname,id.syscall:vals=hitcount:comm=commonpid.execname' >> events/rawsyscalls/sysenter/trigger $ echo 'hist:keys=commonpid.execname,id.syscall:onmatch(rawsyscalls.sysenter).syntheticsysenter($comm, id)' >> events/rawsyscalls/sysenter/trigger $ echo '!hist:keys=commonpid.execname,id.syscall:vals=hitcount:comm=commonpid.execname' >> events/rawsyscalls/sysenter/trigger
[ 100.263533] ================================================================== [ 100.264634] BUG: KASAN: slab-use-after-free in resolvevarrefs+0xc7/0x180 [ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439 [ 100.266320] [ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4 [ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807005459-localhost 04/01/2014 [ 100.268561] Call Trace: [ 100.268902] <TASK> [ 100.269189] dumpstacklvl+0x4c/0x70 [ 100.269680] printreport+0xc5/0x600 [ 100.270165] ? resolvevarrefs+0xc7/0x180 [ 100.270697] ? kasancompletemodereportinfo+0x80/0x1f0 [ 100.271389] ? resolvevarrefs+0xc7/0x180 [ 100.271913] kasanreport+0xbd/0x100 [ 100.272380] ? resolvevarrefs+0xc7/0x180 [ 100.272920] asanload8+0x71/0xa0 [ 100.273377] resolvevarrefs+0xc7/0x180 [ 100.273888] eventhisttrigger+0x749/0x860 [ 100.274505] ? kasansavestack+0x2a/0x50 [ 100.275024] ? kasansettrack+0x29/0x40 [ 100.275536] ? pfxeventhisttrigger+0x10/0x10 [ 100.276138] ? ksyswrite+0xd1/0x170 [ 100.276607] ? dosyscall64+0x3c/0x90 [ 100.277099] ? entrySYSCALL64afterhwframe+0x6e/0xd8 [ 100.277771] ? destroyhistdata+0x446/0x470 [ 100.278324] ? eventhisttriggerparse+0xa6c/0x3860 [ 100.278962] ? pfxeventhisttriggerparse+0x10/0x10 [ 100.279627] ? kasancheckwrite+0x18/0x20 [ 100.280177] ? mutexunlock+0x85/0xd0 [ 100.280660] ? pfxmutexunlock+0x10/0x10 [ 100.281200] ? kfree+0x7b/0x120 [ 100.281619] ? kasanslabfree+0x15d/0x1d0 [ 100.282197] ? eventtriggerwrite+0xac/0x100 [ 100.282764] ? kasanslabfree+0x16/0x20 [ 100.283293] ? kmemcachefree+0x153/0x2f0 [ 100.283844] ? schedmmcidremoteclear+0xb1/0x250 [ 100.284550] ? pfxschedmmcidremoteclear+0x10/0x10 [ 100.285221] ? eventtriggerwrite+0xbc/0x100 [ 100.285781] ? kasancheckread+0x15/0x20 [ 100.286321] ? bitmapweight+0x66/0xa0 [ 100.286833] ? findnextbit+0x46/0xe0 [ 100.287334] ? taskmmcidwork+0x37f/0x450 [ 100.287872] eventtriggerscall+0x84/0x150 [ 100.288408] traceeventbuffercommit+0x339/0x430 [ 100.289073] ? ringbuffereventdata+0x3f/0x60 [ 100.292189] traceeventraweventsysenter+0x8b/0xe0 [ 100.295434] syscalltraceenter.constprop.0+0x18f/0x1b0 [ 100.298653] syscallenterfromusermode+0x32/0x40 [ 100.301808] dosyscall64+0x1a/0x90 [ 100.304748] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 100.307775] RIP: 0033:0x7f686c75c1cb [ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48 [ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIGRAX: 0000000000000021 [ 100.321200] RA ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ipvti: fix potential slab-use-after-free in decodesession6
When ipvti device is set to the qdisc of the sfb type, the cb field of the sent skb may be modified during enqueuing. Then, slab-use-after-free may occur when ipvti device sends IPv6 packets. As commit f855691975bb ("xfrm6: Fix the nexthdr offset in decodesession6.") showed, xfrmdecodesession was originally intended only for the receive path. IP6CB(skb)->nhoff is not set during transmission. Therefore, set the cb field in the skb to 0 before sending packets.