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

nvme-pci: ensure we're polling a polled queue

A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.

fbdev: Fix doregisterframebuffer to prevent null-ptr-deref in fbvideomodetovar

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

tls: fix handling of zero-length records on the rxlist

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rxlist. Next recvmsg() will pick it up from there.

Queuing the skb to rxlist after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rxlist, and it's zero length.

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

espintcp: remove encap socket caching to avoid reference leak

The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.

The reference chain is: xfrmstate -> enacpsk -> netns

Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.

This patch results in a small (~2% in my tests) performance regression.

A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.

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

fs/ntfs3: Mark inode as bad as soon as error detected in mienumattr()

Extended the mienumattr() function interface with an additional parameter, struct ntfsinode ni, to allow marking the inode as bad as soon as an error is detected.

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

nfsd: don't ignore the return code of svcprocregister()

Currently, nfsdprocstatinit() ignores the return value of svcprocregister(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.

Fix nfsdprocstatinit() to return the same type of pointer as svcprocregister(), and fix up nfsdnetinit() to check that and fail the nfsdnet construction if it occurs.

svcprocregister() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsdnet construction codepath, so if this happens, return -ENOMEM.

A vulnerability was found in Linux Foundation Magma 1.9.0. The affected element is an unknown function of the file tasks/amf/amffsm.cpp of the component Registration Complete Message Handler. The manipulation results in improper authentication. The attack can be launched remotely. The exploit has been made public and could be used.

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

nfsd: clear aclaccess/acldefault after releasing them

If getting acldefault fails, aclaccess and acldefault will be released simultaneously. However, aclaccess will still retain a pointer pointing to the released posixacl, which will trigger a WARNING in nfs3svcreleasegetacl like this:

------------[ cut here ]------------ refcountt: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcountwarnsaturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcountwarnsaturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcountwarnsaturate+0xb5/0x170 ? warn+0xa5/0x140 ? refcountwarnsaturate+0xb5/0x170 ? reportbug+0x1b1/0x1e0 ? handlebug+0x53/0xa0 ? excinvalidop+0x17/0x40 ? asmexcinvalidop+0x1a/0x20 ? ticknohztickstopped+0x1e/0x40 ? refcountwarnsaturate+0xb5/0x170 ? refcountwarnsaturate+0xb5/0x170 nfs3svcreleasegetacl+0xc9/0xe0 svcprocesscommon+0x5db/0xb60 ? pfxsvcprocesscommon+0x10/0x10 ? rcureadunlock+0x69/0xa0 ? pfxnfsddispatch+0x10/0x10 ? svcxprtreceived+0xa1/0x120 ? xdrinitdecode+0x11d/0x190 svcprocess+0x2a7/0x330 svchandlexprt+0x69d/0x940 svcrecv+0x180/0x2d0 nfsd+0x168/0x200 ? pfxnfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: paniconwarn set ...

Clear aclaccess/acldefault after posixaclrelease is called to prevent UAF from being triggered.

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

net/sched: actapi: use RCU with deferred freeing for action lifecycle

When NEWTFILTER and DELFILTER are run concurrently it is possible to create a race with an associated action.

Let's illustrate with CPU0 running NEWTFILTER and CPU1 running DELFILTER:

0: mutexlock() <-- holds the idr lock 0: rcureadlock() 0: p = idrfind(idr, index) <-- action p is valid (RCU protects IDR) 0: mutexunlock() <-- releases the idr lock 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) <-- Action removed from IDR 1: mutexunlock() <-- mutex released allowing us to delete the action 1: tcfactioncleanup(p); kfree(p) <-- Kfrees p immediately, no deferral 0: refcountincnotzero(&p->tcfarefcnt) <-- ouch, UAF p points to freed memory

This patch fixes the race condition between NEWTFILTER and DELFILTER by adding struct rcuhead to tcaction used in the deferral and introducing a callrcu() in the delete path to defer the final kfree().

Note: this is a revert of commit d7fb60b9cafb ("netsched: get rid of tcfarcu") but also modernization/simplification to directly use kfreercu().

Let's illustrate the new restored code path:

0: rcureadlock() 1: refcountdecandmutexlock() <-- refcnt 1->0, mutex held 1: idrremove(idr, index) 1: mutexunlock() 1: callrcu(&p->tcfarcu, tcfactionrcufree) <-- defer kfree after grace period 0: p = idrfind(idr, index) 0: refcountincnotzero(&p->tcfarefcnt) <-- fails, refcnt already 0 1: rcureadunlock() <-- release so freeing can run after grace period

After CPU1 calls idrremove(), the object is no longer reachable through the IDR. CPU0's subsequent idrfind() will return NULL, and even if it still held a stale pointer, the immediate kfree() is now deferred until after the RCU grace period, so no UAF can occur.

A vulnerability was identified in Linux Foundation Magma 1.9.0. This affects an unknown function of the component SecurityModeComplete Handler. Such manipulation leads to improper validation of integrity check value. The attack may be launched remotely. The exploit is publicly available and might be used.

A weakness has been identified in Linux Foundation Magma 1.9.0. Affected is an unknown function of the file ngapamfhandlers.c of the component NGSetup Handler. Executing a manipulation can lead to state issue. The attack can be executed remotely. The exploit has been made available to the public and could be used for attacks.

A security vulnerability has been detected in Linux Foundation Magma 1.9.0. Affected by this vulnerability is an unknown functionality of the file tasks/ngap/ngapamf.c of the component gNB Termination Handler. The manipulation leads to denial of service. The attack is possible to be carried out remotely. The exploit has been disclosed publicly and may be used.

A vulnerability was determined in Linux Foundation Magma 1.9.0. The impacted element is an unknown function of the component InitialUEMessage Handler. This manipulation causes information disclosure. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized.

A security flaw has been discovered in Linux Foundation Magma 1.9.0. This impacts an unknown function of the component NGSetupRequest Handler. Performing a manipulation of the argument NG-IoT-DefaultPagingDRX results in improper input validation. Remote exploitation of the attack is possible. The exploit has been released to the public and may be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.

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

usb: core: config: Prevent OOB read in SS endpoint companion parsing

usbparsessendpointcompanion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.

Fix this up by checking the size first before looking at any of the fields in the descriptor.

Bluetooth: hciconn: fix potential UAF in createbigsync

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

media: cx231xx: set devicecaps for 417

The videodevice for the MPEG encoder did not set devicecaps.

Add this, otherwise the video device can't be registered (you get a WARNON instead).

Not seen before since currently 417 support is disabled, but I found this while experimenting with it.

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

ppp: Fix KMSAN uninit-value warning with bpf

Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.

The following code can generate a PPP filter BPF program: ''' struct bpfprogram fp; pcapt handle; handle = pcapopendead(DLTPPPPPPD, 65535); pcapcompile(handle, &fp, "ip and outbound", 0, 0); bpfdump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.

As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.

The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.

For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.

[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000

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

scsi: qla2xxx: Implement ref count for SRB

The timeout handler and the done function are racing. When qla2x00asynciocbtimeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xxasyncgpscspdone() releases the SRB unconditionally. When scheduling back to qla2x00asynciocbtimeout() qla24xxasyncabortcmd() will access an freed sp->qpair pointer:

qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xxhandlegpscevent 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xxasyncabortcmd+0x1b/0x1c0 [qla2xxx]

Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.

When we are able to cancel a timer (deltimer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.

If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling krefput().

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

netfilter: ebtables: fix OOB read in compatmtwfromuser

Luxiao Xu says:

The function compatmtwfromuser() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied matchsize/targetsize.

When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN.

This fix introduces a check to ensure matchsize is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets.

AFAIU this is relevant for matches that need to go though match->compatfromuser() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace).

The ->compatfromuser() callbacks assume they can read compatsize bytes, so they need this extra check.

Based on an earlier patch from Luxiao Xu.

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:

media: iris: Fix use-after-free in irisreleaseinternalbuffers()

The recent change in commit 1dabf00ee206 ("media: iris: gen1: Destroy internal buffers after FW releases") introduced a regression where sessionreleasebuf() may free the buffer. The caller, irisreleaseinternalbuffers(), continued to access buffer after the call, leading to a potential use-after-free.

Fix this by setting BUFATTRPENDINGRELEASE before calling sessionreleasebuf(), and reverting the flag if the call fails. This ensures no dereference occurs after potential freeing.

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

drm/xe: Fix dma-buf attachment leak in xegemprimeimport()

When xedmabufinitobj() fails, the attachment from dmabufdynamicattach() is not detached. Add dmabufdetach() before returning the error. Note: we cannot use goto outerr here because xedmabufinitobj() already frees bo on failure, and outerr would double-free it.

(cherry picked from commit a828eb185aac41800df8eae4b60501ccc0dbbe51)

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

hwmon: (pmbus/q54sj108a2) fix stack overflow in debugfs read

The q54sj108a2debugfsread function suffers from a stack buffer overflow due to incorrect arguments passed to bin2hex(). The function currently passes 'data' as the destination and 'datachar' as the source.

Because bin2hex() converts each input byte into two hex characters, a 32-byte block read results in 64 bytes of output. Since 'data' is only 34 bytes (I2CSMBUSBLOCKMAX + 2), this writes 30 bytes past the end of the buffer onto the stack.

Additionally, the arguments were swapped: it was reading from the zero-initialized 'datachar' and writing to 'data', resulting in all-zero output regardless of the actual I2C read.

Fix this by: 1. Expanding 'datachar' to 66 bytes to safely hold the hex output. 2. Correcting the bin2hex() argument order and using the actual read count. 3. Using a pointer to select the correct output buffer for the final simplereadfrombuffer call.

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

ksmbd: fix use-after-free by using callrcu() for oplockinfo

ksmbd currently frees oplockinfo immediately using kfree(), even though it is accessed under RCU read-side critical sections in places like opinfoget() and procshowfiles().

Since there is no RCU grace period delay between nullifying the pointer and freeing the memory, a reader can still access oplockinfo structure after it has been freed. This can leads to a use-after-free especially in opinfoget() where atomicincnotzero() is called on already freed memory.

Fix this by switching to deferred freeing using callrcu().

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

smb: client: fix in-place encryption corruption in SMB2write()

SMB2write() places write payload in iov[1..n] as part of rqiov. smb3inittransformrq() pointer-shares rqiov, so cryptmessage() encrypts iov[1] in-place, replacing the original plaintext with ciphertext. On a replayable error, the retry sends the same iov[1] which now contains ciphertext instead of the original data, resulting in corruption.

The corruption is most likely to be observed when connections are unstable, as reconnects trigger write retries that re-send the already-encrypted data.

This affects SFU mknod, MF symlinks, etc. On kernels before 6.10 (prior to the netfs conversion), sync writes also used this path and were similarly affected. The async write path wasn't unaffected as it uses rqiter which gets deep-copied.

Fix by moving the write payload into rqiter via ioviterkvec(), so smb3inittransformrq() deep-copies it before encryption.

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

drm/amdgpu: validate doorbelloffset in user queue creation

amdgpuuserqgetdoorbellindex() passes the user-provided doorbelloffset to amdgpudoorbellindexonbar() without bounds checking. An arbitrarily large doorbelloffset can cause the calculated doorbell index to fall outside the allocated doorbell BO, potentially corrupting kernel doorbell space.

Validate that doorbelloffset falls within the doorbell BO before computing the BAR index, using u64 arithmetic to prevent overflow.

(cherry picked from commit de1ef4ffd70e1d15f0bf584fd22b1f28cbd5e2ec)

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

wifi: mac80211: always free skb on ieee80211txprepareskb() failure

ieee80211txprepareskb() has three error paths, but only two of them free the skb. The first error path (ieee80211txprepare() returning TXDROP) does not free it, while invoketxhandlers() failure and the fragmentation check both do.

Add kfreeskb() to the first error path so all three are consistent, and remove the now-redundant frees in callers (ath9k, mt76, mac80211hwsim) to avoid double-free.

Document the skb ownership guarantee in the function's kdoc.

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

ksmbd: fix buffer validation by including null terminator size in EA length

The smb2setea function, which handles Extended Attributes (EA), was performing buffer validation checks that incorrectly omitted the size of the null terminating character (+1 byte) for EA Name. This patch fixes the issue by explicitly adding '+ 1' to EaNameLength where the null terminator is expected to be present in the buffer, ensuring the validation accurately reflects the total required buffer size.