In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Validate GPIO pin LUT table size before iterating

[Why&How] The GPIO pin table parsers in getgpioi2cinfo() and biosparsergetgpiopininfo() derive an element count from the VBIOS tableheader.structuresize field, then iterate over gpiopin[] entries. However, GETIMAGE() only validates that the table header itself fits within the BIOS image. If the VBIOS reports a structuresize larger than the actual mapped data, the loop reads past the end of the BIOS image, causing an out-of-bounds read.

Fix this by calling biosgetimage() to validate that the full claimed structuresize is accessible within the BIOS image before entering the loop in both functions.

(cherry picked from commit ba5e95b43b773ae1bf1f66ee6b31eb774e65afe3)

In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Reject zero-length property entries in validator

tbpropertyentryvalid() accepts entries with length == 0 for DIRECTORY, DATA, and TEXT types. A zero-length TEXT entry passes validation but causes an underflow in the null-termination logic:

property->value.text[property->length 4 - 1] = '\0';

When property->length is 0 this writes to offset -1 relative to the allocation.

Reject zero-length entries early in the validator since they have no valid representation in the XDomain property protocol.

In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Clamp XDomain response data copy to allocation size

tbxdppropertiesrequest() derives the per-packet copy length from the response header without checking that it fits in the previously allocated data buffer. A malicious peer can set its length field larger than the declared datalength, causing memcpy to write past the kcalloc allocation.

Clamp the per-packet copy length so that the cumulative offset never exceeds datalen.

In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Bound root directory content to block size

tbpropertyparsedir() does not check that contentoffset + contentlen fits within blocklen for the root directory case. When rootdir->length equals or exceeds blocklen - 2, the entry loop reads past the allocated property block.

Add a bounds check after computing contentoffset and contentlen to reject directories whose content extends past the block.

In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Validate XDomain request packet size before type cast

tbxdphandlerequest() casts the received packet buffer to protocol-specific structs without verifying that the allocation is large enough for the target type. A peer can send a minimal XDomain packet that passes the generic header length check but is shorter than the struct accessed after the cast, causing out-of- bounds reads from the kmemdup allocation.

Plumb the packet length through xdomainrequestwork and validate it against the expected struct size before each cast.

In the Linux kernel, the following vulnerability has been resolved:

thunderbolt: Limit XDomain response copy to actual frame size

tbxdomaincopy() copies req->responsesize bytes from the received packet buffer regardless of the actual frame size. When a short response arrives, this reads past the valid frame data in the DMA pool buffer into stale contents from previous transactions.

Use the minimum of frame size and expected response size for the copy length.

drm/amd/display: Bound VBIOS record-chain walk loops

In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Clamp VBIOS HDMI retimer register count to array size

[Why & How] The VBIOS integrated info tables (v111 and v21) contain HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C register settings into fixed-size arrays (dpexthdmiregsettings[9] and dpexthdmi6gregsettings[3]). These u8 fields are not validated before use, so a malformed VBIOS can specify values up to 255, causing an out-of-bounds heap write during driver probe.

Clamp each register count to the destination array size using mint() before the copy loops, in both getintegratedinfov11() and getintegratedinfov21().

(cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)

In the Linux kernel, the following vulnerability has been resolved:

sctp: stream: fully roll back denied add-stream state

When ADDOUTSTREAMS is denied, SCTP only shrinks the queued chunks and then lowers outcnt. That leaves removed stream metadata behind, so a later re-add can reuse a stale ext and hit a null-pointer dereference in the scheduler get path.

Fix the rollback by tearing down the removed stream state the same way other stream resizes do. Unschedule the current scheduler state, drop the removed stream ext state with sctpstreamoutqmigrate(), and then reschedule the remaining streams.

This keeps scheduler-private RR/FC/PRIO lists consistent while fully rolling back denied outgoing stream additions.

In the Linux kernel, the following vulnerability has been resolved:

ntb: ntbhwswitchtec: Fix array-index-out-of-bounds access

Number of MW LUTs depends on NTB configuration and can be set to MAXMWS, This patch protects against invalid index out of bounds access to mwsizes When invalid access print message to user that configuration is not valid.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconntrackh323: fix OOB read in decodechoice()

In decodechoice(), the boundary check before getlen() uses the variable len, which is still 0 from its initialization at the top of the function:

unsigned int type, ext, len = 0; ... if (ext || (son->attr & OPEN)) { BYTEALIGN(bs); if (nfh323errorboundary(bs, len, 0)) / len is 0 here / return H323ERRORBOUND; len = getlen(bs); / OOB read /

When the bitstream is exactly consumed (bs->cur == bs->end), the check nfh323errorboundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent getlen() call then dereferences bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, getlen() reads a second byte as well.

This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nfconntrackh323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer.

Fix this by checking for 2 bytes (the maximum that getlen() may read) instead of the uninitialized len. This matches the pattern used at every other getlen() call site in the same file, where the caller checks for 2 bytes of available data before calling getlen().

In the Linux kernel, the following vulnerability has been resolved:

ntb: ntbhwswitchtec: Fix shift-out-of-bounds for 0 mw lut

Number of MW LUTs depends on NTB configuration and can be set to zero, in such scenario rounddownpowoftwo will cause undefined behaviour and should not be performed. This patch ensures that rounddownpowoftwo is called on valid value.

In the Linux kernel, the following vulnerability has been resolved:

xfrm: hold dev ref until after transportfinish NFHOOK

After async crypto completes, xfrminputresume() calls devput() immediately on re-entry before the skb reaches transportfinish. The skb->dev pointer is then used inside NFHOOK and its okfn, which can race with device teardown.

Remove the devput from the async resumption entry and instead drop the reference after the NFHOOK call in transportfinish, using a saved device pointer since NFHOOK may consume the skb. This covers NFDROP, NFQUEUE and NFSTOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix bcackers underflow on duplicate GRPACKMSG

The GRPACKMSG handler in tipcgroupprotorcv() currently decrements bcackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.

Because bcackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipcgroupbccong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.

Fix this by ignoring duplicate or stale ACKs before touching bcacked or bcackers. This makes repeated GRPACKMSG handling idempotent and prevents the underflow path.

In the Linux kernel, the following vulnerability has been resolved:

net/sched: actife: Fix metalist update behavior

Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op:

[ 138.423369][ C1] ================================================================== [ 138.424317][ C1] BUG: KASAN: slab-out-of-bounds in ifetlvmetaencode (net/ife/ife.c:168) [ 138.424906][ C1] Write of size 4 at addr ffff8880077f4ffe by task ifeoutoutbou/255 [ 138.425778][ C1] CPU: 1 UID: 0 PID: 255 Comm: ifeoutoutbou Not tainted 7.0.0-rc1-00169-gfbdfa8da05b6 #624 PREEMPT(full) [ 138.425795][ C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 138.425800][ C1] Call Trace: [ 138.425804][ C1] <IRQ> [ 138.425808][ C1] dumpstacklvl (lib/dumpstack.c:122) [ 138.425828][ C1] printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) [ 138.425839][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425844][ C1] ? virtaddrvalid (./arch/x86/include/asm/preempt.h:95 (discriminator 1) ./include/linux/rcupdate.h:975 (discriminator 1) ./include/linux/mmzone.h:2207 (discriminator 1) arch/x86/mm/physaddr.c:54 (discriminator 1)) [ 138.425853][ C1] ? ifetlvmetaencode (net/ife/ife.c:168) [ 138.425859][ C1] kasanreport (mm/kasan/report.c:221 mm/kasan/report.c:597) [ 138.425868][ C1] ? ifetlvmetaencode (net/ife/ife.c:168) [ 138.425878][ C1] kasancheckrange (mm/kasan/generic.c:186 (discriminator 1) mm/kasan/generic.c:200 (discriminator 1)) [ 138.425884][ C1] asanmemset (mm/kasan/shadow.c:84 (discriminator 2)) [ 138.425889][ C1] ifetlvmetaencode (net/ife/ife.c:168) [ 138.425893][ C1] ? ifetlvmetaencode (net/ife/ife.c:171) [ 138.425898][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425903][ C1] ifeencodemetau16 (net/sched/actife.c:57) [ 138.425910][ C1] ? pfxdorawspinlock (kernel/locking/spinlockdebug.c:114) [ 138.425916][ C1] ? asanmemcpy (mm/kasan/shadow.c:105 (discriminator 3)) [ 138.425921][ C1] ? pfxifeencodemetau16 (net/sched/actife.c:45) [ 138.425927][ C1] ? srsoaliasreturnthunk (arch/x86/lib/retpoline.S:221) [ 138.425931][ C1] tcfifeact (net/sched/actife.c:847 net/sched/actife.c:879)

To solve this issue, fix the replace behavior by adding the metalist to the ife rcu data structure.

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:

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:

Input: exc3000 - properly stop timer on shutdown

We need to stop the timer on driver unbind or probe failures, otherwise we get UAF/Oops.

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(&gt->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:

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:

bpf, cpumap: Make sure kthread is running before map update returns

The following warning was reported when running stress-mode enabled xdpredirectcpu with some RT threads:

------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpumapkthreadstop RIP: 0010:putcpumapentry+0xda/0x220 ...... Call Trace: <TASK> ? showregs+0x65/0x70 ? warn+0xa5/0x240 ...... ? putcpumapentry+0xda/0x220 cpumapkthreadstop+0x41/0x60 processonework+0x6b0/0xb80 workerthread+0x96/0x720 kthread+0x1a5/0x1f0 retfromfork+0x3a/0x70 retfromforkasm+0x1b/0x30 </TASK>

The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memory leak in cpumapupdateelem"). The kthread is stopped prematurely by kthreadstop() in cpumapkthreadstop(), and kthread() doesn't call cpumapkthreadrun() at all but XDP program has already queued some frames or skbs into ptrring. So when cpumapringcleanup() checks the ptrring, it will find it was not emptied and report a warning.

An alternative fix is to use cpumapringcleanup() to drop these pending frames or skbs when kthreadstop() returns -EINTR, but it may confuse the user, because these frames or skbs have been handled correctly by XDP program. So instead of dropping these frames or skbs, just make sure the per-cpu kthread is running before cpumapentryalloc() returns.

After apply the fix, the error handle for kthreadstop() will be unnecessary because it will always return 0, so just remove it.