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

block: don't overwrite bipvcnt in biointegritycopyuser()

biointegrityaddpage() already sets bipvcnt to 1 for the bounce segment. Overwriting it with nrvecs breaks bipvcnt <= bipmaxvcnt on WRITE (bipmaxvcnt is 1), so the gap-merge checks in block/blk.h read past the bipvec[] flex array. On READ the read is in bounds but lands on a saved user bvec instead of the bounce.

The line was added for split propagation, but biointegrityclone() doesn't copy bipvcnt and BIPCLONEFLAGS excludes BIPCOPYUSER.

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

pwrseq: core: fix use-after-free in pwrseqdebugfsseqnext()

pwrseqdebugfsseqnext() declares 'next' with free(putdevice), which causes putdevice() to be called on the returned pointer when the variable goes out of scope. This results in a use-after-free since the seqfile framework receives a pointer whose reference has already been dropped.

Simply removing free(putdevice) would fix the UAF but would leak the reference acquired by busfindnextdevice(), as stop() only calls upread(&pwrseqsem) and never releases the device reference.

Fix this by making the reference counting consistent across all seqfile callbacks, matching the standard pattern used by PCI and SCSI:

- start(): use getdevice() so it returns a referenced pointer. - next(): explicitly putdevice(curr) to release the previous device's reference (no NULL check needed - the seqfile framework only calls next() while the previous return was non-NULL). - stop(): putdevice(data) to release the last iterated device's reference, with a NULL guard since stop() may be called with NULL when start() returned NULL or next() reached end-of-sequence.

bpf: Fix helper writes to read-only maps

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

mm: call the securitymmapfile() LSM hook in remapfilepages()

The remapfilepages syscall handler calls dommap() directly, which doesn't contain the LSM security check. And if the process has called personality(READIMPLIESEXEC) before and remapfilepages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux.

So we should check prot by securitymmapfile LSM hook in the remapfilepages syscall handler before dommap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux.

The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1].

The PoC:

$ cat > test.c

int main(void) { sizet pagesz = sysconf(SCPAGESIZE); int mfd = syscall(SYSmemfdcreate, "test", 0); const char buf = mmap(NULL, 4 pagesz, PROTREAD | PROTWRITE, MAPSHARED, mfd, 0); unsigned int old = syscall(SYSpersonality, 0xffffffff); syscall(SYSpersonality, READIMPLIESEXEC | old); syscall(SYSremapfilepages, buf, pagesz, 0, 2, 0); syscall(SYSpersonality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", ORDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); }

$ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted)

[PM: subject line tweaks]

f2fs: fix to check atomicfile in f2fs ioctl interfaces

fs/inode: Prevent dumpmapping() accessing invalid dentry.dname.name

gso: fix udp gso fraglist segmentation after pull from fraglist

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

ksmbd: add refcnt to ksmbdconn struct

When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbdconn struct so that it can be freed when it is no longer used.

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

x86/tdx: Fix "in-kernel MMIO" check

TDX only supports kernel-initiated MMIO operations. The handlemmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not.

However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does getuser() or putuser() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO.

Ensure that the target MMIO address is within the kernel before decoding instruction.

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

accel/ivpu: Add buffer overflow check in MS getinfoioctl

Add validation that the info size returned from the metric stream info query is not exceeded when checked against the allocated buffer size. If the firmware returns a size larger than the buffer, reject the operation with -EOVERFLOW instead of proceeding with an incorrect buffer copy.

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

KVM: arm64: Reassign nestedmmus array behind mmulock

kvm->arch.nestedmmus[] is walked under kvm->mmulock, including from the MMU notifier path (kvmunmapgfnrange() -> kvmnesteds2unmap()), which can run at any time. kvmvcpuinitnested() reallocates the array and frees the old buffer while holding only kvm->arch.configlock, so such a walker can reference the freed array.

Allocate the new array outside of mmulock, as the allocation can sleep. Under the lock, copy the existing entries, fix up the back pointers and reassign the array. Free the old buffer after dropping the lock, as kvfree() can sleep as well.

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

RDMA/mlx5: Fix error path fall-through in mlx5ibdevressrqinit()

mlx5ibdevressrqinit() allocates two SRQs, s0 and s1. When ibcreatesrq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERRPTR s1 to devr->s0 and devr->s1.

This leads to several problems: the lock-free fast path checks "if (devr->s1) return 0;" and treats the ERRPTR as already initialised; users in mlx5ibcreateqp() dereference the freed SRQ or ERRPTR via tomsrq(devr->s0)->msrq.srqn; and mlx5ibdevrescleanup() dereferences the ERRPTR and double-frees s0 on teardown.

Fix by adding the same goto unlock in the s1 failure path.

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

bpf: Preserve id of register in synclinkedregs()

synclinkedregs() copies the id of knownreg to reg when propagating bounds of knownreg to reg using the off of knownreg, but when knownreg was linked to reg like:

knownreg = reg ; both knownreg and reg get same id knownreg += 4 ; knownreg gets off = 4, and its id gets BPFADDCONST

now when a call to synclinkedregs() happens, let's say with the following:

if knownreg >= 10 goto pc+2

knownreg's new bounds are propagated to reg but now reg gets BPFADDCONST from the copy.

This means if another link to reg is created like:

anotherreg = reg ; anotherreg should get the id of reg but assignscalaridbeforemov() sees BPFADDCONST on reg and assigns a new id to it.

As reg has a new id now, knownreg's link to reg is broken. If we find new bounds for knownreg, they will not be propagated to reg.

This can be seen in the selftest added in the next commit:

0: (85) call bpfgetprandomu32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 4: (a5) if r1 < 0xa goto pc+4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 5: (bf) r2 = r0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (a5) if r1 < 0xe goto pc+2 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,varoff=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,varoff=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero

When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPFADDCONST (bug). When 5 is verified, r0 gets a new id (2) and its link with r1 is broken.

After 6 we know r1 has bounds [14, 259] and therefore r0 should have bounds [10, 255], therefore the branch at 7 is always taken. But because r0's id was changed to 2, r1's new bounds are not propagated to r0. The verifier still thinks r0 has bounds [6, 255] before 7 and execution can reach div by zero.

Fix this by preserving id in synclinkedregs() like off and subregdef.

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

netfilter: nfnetlinkqueue: do shared-unconfirmed check before segmentation

Ulrich reports a regression with nfqueue:

If an application did not set the 'FGSO' capability flag and a gso packet with an unconfirmed nfconn entry is received all packets are now dropped instead of queued, because the check happens after skbgsosegment(). In that case, we did have exclusive ownership of the skb and its associated conntrack entry. The elevated use count is due to skbclone happening via skbgsosegment().

Move the check so that its peformed vs. the aggregated packet.

Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time.

For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry.

While at it, simplify nfctdropunconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries.

This only happens with UDP. With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO.

Next patch adds a udpgro test case to cover this scenario.

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

xfrm: Fix work re-schedule after cancel in xfrmnatkeepalivenetfini()

After canceldelayedworksync() is called from xfrmnatkeepalivenetfini(), xfrmstatefini() flushes remaining states via xfrmstatedelete(), which calls xfrmnatkeepalivestateupdated() to re-schedule natkeepalivework.

The following is a simple race scenario:

cpu0 cpu1

cleanupnet() [Round 1] opsundolist() xfrmnetexit() xfrmnatkeepalivenetfini() canceldelayedworksync(natkeepalivework); xfrmstatefini() xfrmstateflush() xfrmstatedelete(x) xfrmstatedelete(x) xfrmnatkeepalivestateupdated(x) scheduledelayedwork(natkeepalivework); rcubarrier(); netcompletefree(); netpassivedec(net); llistadd(&net->deferfreelist, &deferfreelist);

cleanupnet() [Round 2] rcubarrier(); netcompletefree() kmemcachefree(netcachep, net); natkeepalivework() // on freed net

To prevent this, canceldelayedworksync() is replaced with disabledelayedworksync().

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

HID: bpf: prevent buffer overflow in hidhwrequest

right now the returned value is considered to be always valid. However, when playing with HID-BPF, the return value can be arbitrary big, because it's the return value of dispatchhidbpfrawrequests(), which calls the structops and we have no guarantees that the value makes sense.

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

fs/ntfs3: Initialize new folios before use

KMSAN reports an uninitialized value in longestmatchstd(), invoked from ntfscompresswrite(). When new folios are allocated without being marked uptodate and nireadframe() is skipped because the caller expects the frame to be completely overwritten, some reserved folios may remain only partially filled, leaving the rest memory uninitialized.

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

drm/xe/oa: Fix potential UAF in xeoaaddconfigioctl()

In xeoaaddconfigioctl(), we accessed oaconfig->id after dropping metricslock. Since this lock protects the lifetime of oaconfig, an attacker could guess the id and call xeoaremoveconfigioctl() with perfect timing, freeing oaconfig before we dereference it, leading to a potential use-after-free.

Fix this by caching the id in a local variable while holding the lock.

v2: (Matt A) - Dropped mutexunlock(&oa->metricslock) ordering change from xeoaremoveconfigioctl()

(cherry picked from commit 28aeaed130e8e587fd1b73b6d66ca41ccc5a1a31)

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

iommufd: Fix race during abort for file descriptors

fput() doesn't actually call fileoperations release() synchronously, it puts the file on a work queue and it will be released eventually.

This is normally fine, except for iommufd the file and the iommufdobject are tied to gether. The file has the object as it's privatedata and holds a users refcount, while the object is expected to remain alive as long as the file is.

When the allocation of a new object aborts before installing the file it will fput() the file and then go on to immediately kfree() the obj. This causes a UAF once the workqueue completes the fput() and tries to decrement the users refcount.

Fix this by putting the core code in charge of the file lifetime, and call fputsync() during abort to ensure that release() is called before kfree. fputsync() is a bit too tricky to open code in all the object implementations. Instead the objects tell the core code where the file pointer is and the core will take care of the life cycle.

If the object is successfully allocated then the file will hold a users refcount and the iommufdobject cannot be destroyed.

It is worth noting that close(); ioctl(IOMMUDESTROY); doesn't have an issue because close() is already using a synchronous version of fput().

The UAF looks like this:

BUG: KASAN: slab-use-after-free in iommufdeventqfopsrelease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 Write of size 4 at addr ffff888059c97804 by task syz.0.46/6164

CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:183 [inline] kasancheckrange+0x100/0x1b0 mm/kasan/generic.c:189 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicfetchsubrelease include/linux/atomic/atomic-instrumented.h:400 [inline] refcountdec include/linux/refcount.h:455 [inline] refcountdec include/linux/refcount.h:476 [inline] iommufdeventqfopsrelease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 fput+0x402/0xb70 fs/filetable.c:468 taskworkrun+0x14d/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xeb/0x110 kernel/entry/common.c:43 exittousermodeprepare include/linux/irq-entry-common.h:225 [inline] syscallexittousermodework include/linux/entry-common.h:175 [inline] syscallexittousermode include/linux/entry-common.h:210 [inline] dosyscall64+0x41c/0x4c0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

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

s390/mm: Do not map lowcore with identity mapping

Since the identity mapping is pinned to address zero the lowcore is always also mapped to address zero, this happens regardless of the relocatelowcore command line option. If the option is specified the lowcore is mapped twice, instead of only once.

This means that NULL pointer accesses will succeed instead of causing an exception (low address protection still applies, but covers only parts). To fix this never map the first two pages of physical memory with the identity mapping.

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

spi: cs42l43: Property entry should be a null-terminated array

The software node does not specify a count of property entries, so the array must be null-terminated.

When unterminated, this can lead to a fault in the downstream cs35l56 amplifier driver, because the node parse walks off the end of the array into unknown memory.

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

smc: Fix various oops due to inetsock type confusion.

syzbot reported weird splats [0][1] in cipsov4socksetattr() while freeing inetsk(sk)->inetopt.

The address was freed multiple times even though it was read-only memory.

cipsov4socksetattr() did nothing wrong, and the root cause was type confusion.

The cited commit made it possible to create smcsock as an INET socket.

The issue is that struct smcsock does not have struct inetsock as the first member but hijacks AFINET and AFINET6 skfamily, which confuses various places.

In this case, inetsock.inetopt was actually smcsock.clcskdataready(), which is an address of a function in the text segment.

$ pahole -C inetsock vmlinux struct inetsock { ... struct ipoptionsrcu inetopt; / 784 8 /

$ pahole -C smcsock vmlinux struct smcsock { ... void (clcskdataready)(struct sock ); / 784 8 /

The same issue for another field was reported before. [2][3]

At that time, an ugly hack was suggested [4], but it makes both INET and SMC code error-prone and hard to change.

Also, yet another variant was fixed by a hacky commit 98d4435efcbf3 ("net/smc: prevent NULL pointer dereference in txoptget").

Instead of papering over the root cause by such hacks, we should not allow non-INET socket to reuse the INET infra.

Let's add inetsock as the first member of smcsock.

[0]: kvfreecallrcu(): Double-freed call. rcuhead 000000006921da73 WARNING: CPU: 0 PID: 6718 at mm/slabcommon.c:1956 kvfreecallrcu+0x94/0x3f0 mm/slabcommon.c:1955 Modules linked in: CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfreecallrcu+0x94/0x3f0 mm/slabcommon.c:1955 lr : kvfreecallrcu+0x94/0x3f0 mm/slabcommon.c:1955 sp : ffff8000a03a7730 x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3 x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00 x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000 x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360 x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000 Call trace: kvfreecallrcu+0x94/0x3f0 mm/slabcommon.c:1955 (P) cipsov4socksetattr+0x2f0/0x3f4 net/ipv4/cipsoipv4.c:1914 netlblsocksetattr+0x240/0x334 net/netlabel/netlabelkapi.c:1000 smacknetlbladd+0xa8/0x158 security/smack/smacklsm.c:2581 smackinodesetsecurity+0x378/0x430 security/smack/smacklsm.c:2912 securityinodesetsecurity+0x118/0x3c0 security/security.c:2706 vfssetxattrnoperm+0x174/0x5c4 fs/xattr.c:251 vfssetxattrlocked+0x1ec/0x218 fs/xattr.c:295 vfssetxattr+0x158/0x2ac fs/xattr.c:321 dosetxattr fs/xattr.c:636 [inline] filesetxattr+0x1b8/0x294 fs/xattr.c:646 pathsetxattrat+0x2ac/0x320 fs/xattr.c:711 dosysfsetxattr fs/xattr.c:761 [inline] sesysfsetxattr fs/xattr.c:758 [inline] arm64sysfsetxattr+0xc0/0xdc fs/xattr.c:758 invokesyscall arch/arm64/kernel/syscall.c:35 [inline] invokesyscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0svccommon+0x130/0x23c arch/arm64/kernel/syscall.c:132 doel0svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t64synchandler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t64sync+0x198/0x19c arch/arm64/kernel/entry.S:600

[ ---truncated---

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

iouring/msgring: ensure iokiocb freeing is deferred for RCU

syzbot reports that defer/local taskwork adding via msgring can hit a request that has been freed:

CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dumpstacklvl+0x189/0x250 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xd2/0x2b0 mm/kasan/report.c:521 kasanreport+0x118/0x150 mm/kasan/report.c:634 ioreqlocalworkadd iouring/iouring.c:1184 [inline] ioreqtaskworkadd+0x589/0x950 iouring/iouring.c:1252 iomsgremotepost iouring/msgring.c:103 [inline] iomsgdataremote iouring/msgring.c:133 [inline] iomsgringdata+0x820/0xaa0 iouring/msgring.c:151 iomsgringdata iouring/msgring.c:173 [inline] iomsgring+0x134/0xa00 iouring/msgring.c:314 ioissuesqe+0x17e/0x4b0 iouring/iouring.c:1739 ioissuesqe+0x165/0xfd0 iouring/iouring.c:1762 iowqsubmitwork+0x6e9/0xb90 iouring/iouring.c:1874 ioworkerhandlework+0x7cd/0x1180 iouring/io-wq.c:642 iowqworker+0x42f/0xeb0 iouring/io-wq.c:696 retfromfork+0x3fc/0x770 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

which is supposed to be safe with how requests are allocated. But msg ring requests alloc and free on their own, and hence must defer freeing to a sane time.

Add an rcuhead and use kfreercu() in both spots where requests are freed. Only the one in iomsgtwcomplete() is strictly required as it has been visible on the other ring, but use it consistently in the other spot as well.

This should not cause any other issues outside of KASAN rightfully complaining about it.

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

virtio-net: xsk: rx: fix the frame's length check

When calling buftoxdp, the len argument is the frame data's length without virtio header's length (vi->hdrlen). We check that len with

xskpoolgetrxframesize() + vi->hdrlen

to ensure the provided len does not larger than the allocated chunk size. The additional vi->hdrlen is because in virtnetaddrecvbufxsk, we use part of XDPPACKETHEADROOM for virtio header and ask the vhost to start placing data from

hardstart + XDPPACKETHEADROOM - vi->hdrlen not hardstart + XDPPACKETHEADROOM

But the first buffer has virtioheader, so the maximum frame's length in the first buffer can only be

xskpoolgetrxframesize() not xskpoolgetrxframesize() + vi->hdrlen

like in the current check.

This commit adds an additional argument to buftoxdp differentiate between the first buffer and other ones to correctly calculate the maximum frame's length.

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

eth: fbnic: avoid double free when failing to DMA-map FW msg

The semantics are that caller of fbnicmbxmapmsg() retains the ownership of the message on error. All existing callers dutifully free the page.

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

wifi: ath12k: Fix buffer overflow in debugfs

If the user tries to write more than 32 bytes then it results in memory corruption. Fortunately, this is debugfs so it's limited to root users.

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

fs/fhandle.c: fix a race in call of haslockedchildren()

maydecodefh() is calling haslockedchildren() while holding no locks. That's an oopsable race...

The rest of the callers are safe since they are holding namespacesem and are guaranteed a positive refcount on the mount in question.

Rename the current haslockedchildren() to haslockedchildren(), make it static and switch the fs/namespace.c users to it.

Make haslockedchildren() a wrapper for haslockedchildren(), calling the latter under readseqlockexcl(&mountlock).

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

gpio: virtuser: fix potential out-of-bound write

If the caller wrote more characters, count is truncated to the max available space in "simplewritetobuffer". Check that the input size does not exceed the buffer size. Write a zero termination afterwards.

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

HID: bpf: abort dispatch if device destroyed

The current HID bpf implementation assumes no output report/request will go through it after hidbpfdestroydevice() has been called. This leads to a bug that unplugging certain types of HID devices causes a cleaned- up SRCU to be accessed. The bug was previously a hidden failure until a recent x86 percpu change [1] made it access not-present pages.

The bug will be triggered if the conditions below are met:

A) a device under the driver has some LEDs on B) hidlldriver->request() is uninplemented (e.g., logitech-djreceiver)

If condition A is met, hidinputledworker() is always scheduled after hidbpfdestroydevice().

hiddestroydevice hidbpfdestroydevice cleanupsrcustruct(&hdev->bpf.srcu) hidremovedevice ... ledclassdevunregister ledtriggerset(ledcdev, NULL) ledsetbrightness(ledcdev, LEDOFF) ... inputinjectevent inputeventdispose hidinputinputevent schedulework(&hid->ledwork) [hidinputledworker]

This is fine when condition B is not met, where hidinputledworker() calls hidlldriver->request(). This is the case for most HID drivers, which implement it or use the generic one from usbhid. The driver itself or an underlying driver will then abort processing the request.

Otherwise, hidinputledworker() tries hidhwoutputreport() and leads to the bug.

hidinputledworker hidhwoutputreport dispatchhidbpfoutputreport srcureadlock(&hdev->bpf.srcu) srcureadunlock(&hdev->bpf.srcu, idx)

The bug has existed since the introduction [2] of dispatchhidbpfoutputreport(). However, the same bug also exists in dispatchhidbpfrawrequests(), and I've reproduced (no visible effect because of the lack of [1], but confirmed bpf.destroyed == 1) the bug against the commit (i.e., the Fixes:) introducing the function. This is because hidinputledworker() falls back to hidhwrawrequest() when hidlldriver->outputreport() is uninplemented (e.g., logitech- djreceiver).

hidinputledworker hidhwoutputreport: -ENOSYS hidhwrawrequest dispatchhidbpfrawrequests srcureadlock(&hdev->bpf.srcu) srcureadunlock(&hdev->bpf.srcu, idx)

Fix the issue by returning early in the two mentioned functions if hidbpf has been marked as destroyed. Though dispatchhidbpfdeviceevent() handles input events, and there is no evidence that it may be called after the destruction, the same check, as a safety net, is also added to it to maintain the consistency among all dispatch functions.

The impact of the bug on other architectures is unclear. Even if it acts as a hidden failure, this is still dangerous because it corrupts whatever is on the address calculated by SRCU. Thus, CC'ing the stable list.

[1]: commit 9d7de2aa8b41 ("x86/percpu/64: Use relative percpu offsets") [2]: commit 9286675a2aed ("HID: bpf: add HID-BPF hooks for hidhwoutputreport")