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.

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

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.

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:

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:

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:

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:

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:

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:

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.

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

ice: fix Rx page leak on multi-buffer frames

The iceputrxmbuf() function handles calling iceputrxbuf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver.

It works by iterating over the buffers from firstdesc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed.

If the hardware posts a descriptor with a size of 0, the logic used in iceputrxmbuf() breaks. Such descriptors get skipped and don't get added as fragments in iceaddxdpfrag. Since the buffer isn't counted as a fragment, we do not iterate over it in iceputrxmbuf(), and thus we don't call iceputrxbuf().

Because we don't call iceputrxbuf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment nexttoalloc.

The icereuserxpage() assumes that the nexttoalloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the nexttoalloc buffer, losing track of the old page.

Note that this leak only occurs for multi-buffer frames. The iceputrxmbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with "jumbo frames" used by 9K MTU.

To fix iceputrxmbuf(), we need to make sure to call iceputrxbuf() on all buffers between firstdesc and nexttoclean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in icegetpgcnts().

Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the nexttoclean element just past the current frame. Unlike i40e, the iceputrxmbuf() function does call iceputrxbuf() on the last buffer of the frame indicating the end of packet.

For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecntbias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecntbias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss.

The xdpxmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdpxmit pointer argument from iceputrxmbuf(). Instead, set xdpxmit in the icecleanrxirq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame.

Move the increment of the ntc local variable to ensure its updated before all calls to icegetpgcnts() or iceputrxmbuf(), as the loop logic requires the index of the element just after the current frame.

Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rxring.

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:

virtio-net: ensure the received length does not exceed allocated size

In xdplinearizepage, when reading the following buffers from the ring, we forget to check the received length with the true allocate size. This can lead to an out-of-bound read. This commit adds that missing check.

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

net/sched: Always pass notifications when child class becomes empty

Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlennotify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.

The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:

tc qdisc add dev lo root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo parent 1: classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1 tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0 tc qdisc add dev lo parent 2:1 handle 3: netem tc qdisc add dev lo parent 3:1 handle 4: blackhole

echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888 tc class delete dev lo classid 1:1 echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888

Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisctreereducebacklog always calls qlennotify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdiscreset() and / or qdiscpurgequeue() which ultimately resets its qlen to 0 thus causing the following qdisctreereducebacklog() to report to the parent. Note that this may call qlennotify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlennotify() handlers idempotent.

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

powerpc/bpf: fix JIT code size calculation of bpf trampoline

archbpftrampolinesize() provides JIT size of the BPF trampoline before the buffer for JIT'ing it is allocated. The total number of instructions emitted for BPF trampoline JIT code depends on where the final image is located. So, the size arrived at with the dummy pass in archbpftrampolinesize() can vary from the actual size needed in archpreparebpftrampoline(). When the instructions accounted in archbpftrampolinesize() is less than the number of instructions emitted during the actual JIT compile of the trampoline, the below warning is produced:

WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpfjitcomp.c:981 archpreparebpftrampoline.isra.0+0xd2c/0xdcc

which is:

/ Make sure the trampoline generation logic doesn't overflow / if (image && WARNONONCE(&image[ctx->idx] > (u32 )rwimageend - BPFINSNSAFETY)) {

So, during the dummy pass, instead of providing some arbitrary image location, account for maximum possible instructions if and when there is a dependency with image location for JIT'ing.

calipso: Fix null-ptr-deref in calipsoreq{set,del}attr().

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

schhfsc: make hfscqlennotify() idempotent

hfscqlennotify() is not idempotent either and not friendly to its callers, like fqcodeldequeue(). Let's make it idempotent to ease qdisctreereducebacklog() callers' life:

1. updatevf() decreases cl->clnactive, so we can check whether it is non-zero before calling it.

2. eltreeremove() always removes RB node cl->elnode, but we can use RBEMPTYNODE() + RBCLEARNODE() to make it safe.

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

net: fix udp gso skbsegment after pull from fraglist

Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from fraglist") detected invalid geometry in fraglist skbs and redirects them from skbsegmentlist to more robust skbsegment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skbsegment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust.

If only part of the fraglist payload is pulled into headskb, it will always cause exception when splitting skbs by skbsegment. For detailed call stack information, see below.

Valid SKBGSOFRAGLIST skbs - consist of two or more segments - the headskb holds the protocol headers plus first gsosize - one or more fraglist skbs hold exactly one segment - all but the last must be gsosize

Optional datapath hooks such as NAT and BPF (bpfskbpulldata) can modify fraglist skbs, breaking these invariants.

In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes.

The skbs no longer meets the above SKBGSOFRAGLIST conditions because payload was pulled into headskb, it needs to be linearized before pass to regular skbsegment.

skbsegment+0xcd0/0xd14 udpgsosegment+0x334/0x5f4 udp4ufofragment+0x118/0x15c inetgsosegment+0x164/0x338 skbmacgsosegment+0xc4/0x13c skbgsosegment+0xc4/0x124 validatexmitskb+0x9c/0x2c0 validatexmitskblist+0x4c/0x80 schdirectxmit+0x70/0x404 devqueuexmit+0x64c/0xe5c neighresolveoutput+0x178/0x1c4 ipfinishoutput2+0x37c/0x47c ipfinishoutput+0x194/0x240 ipfinishoutput+0x20/0xf4 ipoutput+0x100/0x1a0 NFHOOK+0xc4/0x16c ipforward+0x314/0x32c iprcv+0x90/0x118 netifreceiveskb+0x74/0x124 processbacklog+0xe8/0x1a4 napipoll+0x5c/0x1f8 netrxaction+0x154/0x314 handlesoftirqs+0x154/0x4b8

[118.376811] [C201134] rxq0pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0pus: [name:mrdump&]PHYSOFFSET: 0x40000000 [118.470827] [C201134] rxq0pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0pus: [name:mrdump&]pc : [0xffffffd79598aefc] skbsegment+0xcd0/0xd14 [118.470900] [C201134] rxq0pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skbsegment+0x3bc/0xd14 [118.470928] [C201134] rxq0pus: [name:mrdump&]sp : ffffffc008013770

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

netfilter: nfsetpipapoavx2: fix initial map fill

If the first field doesn't cover the entire start map, then we must zero out the remainder, else we leak those bits into the next match round map.

The early fix was incomplete and did only fix up the generic C implementation.

A followup patch adds a test case to nftconcatrange.sh.

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.

codel: remove sch->q.qlen check before qdisctreereducebacklog()

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

mm/gup: reject FOLLSPLITPMD with hugetlb VMAs

Patch series "mm: fixes for device-exclusive entries (hmm)", v2.

Discussing the PageTail() call in makedeviceexclusiverange() with Willy, I recently discovered [1] that device-exclusive handling does not properly work with THP, making the hmm-tests selftests fail if THPs are enabled on the system.

Looking into more details, I found that hugetlb is not properly fenced, and I realized that something that was bugging me for longer -- how device-exclusive entries interact with mapcounts -- completely breaks migration/swapout/split/hwpoison handling of these folios while they have device-exclusive PTEs.

The program below can be used to allocate 1 GiB worth of pages and making them device-exclusive on a kernel with CONFIGTESTHMM.

Once they are device-exclusive, these folios cannot get swapped out (proc$pid/smapsrollup will always indicate 1 GiB RSS no matter how much one forces memory reclaim), and when having a memory block onlined to ZONEMOVABLE, trying to offline it will loop forever and complain about failed migration of a page that should be movable.

echo offline > /sys/devices/system/memory/memory136/state echo onlinemovable > /sys/devices/system/memory/memory136/state ./hmm-swap & ... wait until everything is device-exclusive echo offline > /sys/devices/system/memory/memory136/state [ 285.193431][T14882] page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x7f20671f7 pfn:0x442b6a [ 285.196618][T14882] memcg:ffff888179298000 [ 285.198085][T14882] anon flags: 0x5fff0000002091c(referenced|uptodate| dirty|active|owner2|swapbacked|node=1|zone=3|lastcpupid=0x7ff) [ 285.201734][T14882] raw: ... [ 285.204464][T14882] raw: ... [ 285.207196][T14882] page dumped because: migration failure [ 285.209072][T14882] pageowner tracks the page as allocated [ 285.210915][T14882] page last allocated via order 0, migratetype Movable, gfpmask 0x140dca(GFPHIGHUSERMOVABLE|GFPCOMP|GFPZERO), id 14926, tgid 14926 (hmm-swap), ts 254506295376, freets 227402023774 [ 285.216765][T14882] postallochook+0x197/0x1b0 [ 285.218874][T14882] getpagefromfreelist+0x76e/0x3280 [ 285.220864][T14882] allocfrozenpagesnoprof+0x38e/0x2740 [ 285.223302][T14882] allocpagesmpol+0x1fc/0x540 [ 285.225130][T14882] folioallocmpolnoprof+0x36/0x340 [ 285.227222][T14882] vmaallocfolionoprof+0xee/0x1a0 [ 285.229074][T14882] handlemmfault+0x2b38/0x56a0 [ 285.230822][T14882] handlemmfault+0x368/0x9f0 ...

This series fixes all issues I found so far. There is no easy way to fix without a bigger rework/cleanup. I have a bunch of cleanups on top (some previous sent, some the result of the discussion in v1) that I will send out separately once this landed and I get to it.

I wish we could just use some special present PROTNONE PTEs instead of these (non-present, non-none) fake-swap entries; but that just results in the same problem we keep having (lack of spare PTE bits), and staring at other similar fake-swap entries, that ship has sailed.

With this series, makedeviceexclusive() doesn't actually belong into mm/rmap.c anymore, but I'll leave moving that for another day.

I only tested this series with the hmm-tests selftests due to lack of HW, so I'd appreciate some testing, especially if the interaction between two GPUs wanting a device-exclusive entry works as expected.

<program> #include <stdio.h> #include <fcntl.h> #include <stdint.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <sys/mman.h> #include <sys/ioctl.h> #include <linux/types.h> #include <linux/ioctl.h>

#define HMMDMIRROREXCLUSIVE IOWR('H', 0x05, struct hmmdmirrorcmd)

struct hmmdmirrorcmd { u64 addr; u64 ptr; u64 npages; u64 cpages; u64 faults; };

const sizet size = 1 1024 1024 1024ul; const sizet chunksize = 2 1024 1024ul;

int m ---truncated---

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

keys: Fix UAF in keyput()

Once a key's reference count has been reduced to 0, the garbage collector thread may destroy it at any time and so keyput() is not allowed to touch the key after that point. The most keyput() is normally allowed to do is to touch keygcwork as that's a static global variable.

However, in an effort to speed up the reclamation of quota, this is now done in keyput() once the key's usage is reduced to 0 - but now the code is looking at the key after the deadline, which is forbidden.

Fix this by using a flag to indicate that a key can be gc'd now rather than looking at the key's refcount in the garbage collector.

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

btrfs: fix use-after-free on inode when scanning root during em shrinking

At btrfsscanroot() we are accessing the inode's root (and fsinfo) in a call to btrfsfsclosing() after we have scheduled the inode for a delayed iput, and that can result in a use-after-free on the inode in case the cleaner kthread does the iput before we dereference the inode in the call to btrfsfsclosing().

Fix this by using the fsinfo stored already in a local variable instead of doing inode->root->fsinfo.

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

net: hns3: fixed hclgefetchpfreg accesses bar space out of bounds issue

The TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs 1024-1279 are in different BAR space addresses. However, hclgefetchpfreg does not distinguish the tqp space information when reading the tqp space information. When the number of TQPs is greater than 1024, access bar space overwriting occurs. The problem of different segments has been considered during the initialization of tqp.iobase. Therefore, tqp.iobase is directly used when the queue is read in hclgefetchpfreg.

The error message:

Unable to handle kernel paging request at virtual address ffff800037200000 pc : hclgefetchpfreg+0x138/0x250 [hclge] lr : hclgegetregs+0x84/0x1d0 [hclge] Call trace: hclgefetchpfreg+0x138/0x250 [hclge] hclgegetregs+0x84/0x1d0 [hclge] hns3getregs+0x2c/0x50 [hns3] ethtoolgetregs+0xf4/0x270 devethtool+0x674/0x8a0 devioctl+0x270/0x36c sockdoioctl+0x110/0x2a0 sockioctl+0x2ac/0x530 arm64sysioctl+0xa8/0x100 invokesyscall+0x4c/0x124 el0svccommon.constprop.0+0x140/0x15c doel0svc+0x30/0xd0 el0svc+0x1c/0x2c el0synchandler+0xb0/0xb4 el0sync+0x168/0x180

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

net: avoid potential UAF in defaultoperstate()

syzbot reported an UAF in defaultoperstate() [1]

Issue is a race between device and netns dismantles.

After calling rtnlunlock() from netdevruntodo(), we can not assume the netns of each device is still alive.

Make sure the device is not in NETREGUNREGISTERED state, and add an ASSERTRTNL() before the call to devgetbyindex().

We might move this ASSERTRTNL() in devgetbyindex() in the future.

[1]

BUG: KASAN: slab-use-after-free in devgetbyindex+0x5d/0x110 net/core/dev.c:852 Read of size 8 at addr ffff888043eba1b0 by task syz.0.0/5339

CPU: 0 UID: 0 PID: 5339 Comm: syz.0.0 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 devgetbyindex+0x5d/0x110 net/core/dev.c:852 defaultoperstate net/core/linkwatch.c:51 [inline] rfc2863policy+0x224/0x300 net/core/linkwatch.c:67 linkwatchdodev+0x3e/0x170 net/core/linkwatch.c:170 netdevruntodo+0x461/0x1000 net/core/dev.c:10894 rtnlunlock net/core/rtnetlink.c:152 [inline] rtnlnetunlock include/linux/rtnetlink.h:133 [inline] rtnldellink+0x760/0x8d0 net/core/rtnetlink.c:3520 rtnetlinkrcvmsg+0x791/0xcf0 net/core/rtnetlink.c:6911 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2541 netlinkunicastkernel net/netlink/afnetlink.c:1321 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1347 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1891 socksendmsgnosec net/socket.c:711 [inline] socksendmsg+0x221/0x270 net/socket.c:726 syssendmsg+0x52a/0x7e0 net/socket.c:2583 syssendmsg net/socket.c:2637 [inline] syssendmsg+0x269/0x350 net/socket.c:2669 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f2a3cb80809 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f2a3d9cd058 EFLAGS: 00000246 ORIGRAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f2a3cd45fa0 RCX: 00007f2a3cb80809 RDX: 0000000000000000 RSI: 0000000020000000 RDI: 0000000000000008 RBP: 00007f2a3cbf393e R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f2a3cd45fa0 R15: 00007ffd03bc65c8 </TASK>

Allocated by task 5339: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:394 kasankmalloc include/linux/kasan.h:260 [inline] kmalloccachenoprof+0x243/0x390 mm/slub.c:4314 kmallocnoprof include/linux/slab.h:901 [inline] kmallocarraynoprof include/linux/slab.h:945 [inline] netdevcreatehash net/core/dev.c:11870 [inline] netdevinit+0x10c/0x250 net/core/dev.c:11890 opsinit+0x31e/0x590 net/core/netnamespace.c:138 setupnet+0x287/0x9e0 net/core/netnamespace.c:362 copynetns+0x33f/0x570 net/core/netnamespace.c:500 createnewnamespaces+0x425/0x7b0 kernel/nsproxy.c:110 unsharensproxynamespaces+0x124/0x180 kernel/nsproxy.c:228 ksysunshare+0x57d/0xa70 kernel/fork.c:3314 dosysunshare kernel/fork.c:3385 [inline] sesysunshare kernel/fork.c:3383 [inline] x64sysunshare+0x38/0x40 kernel/fork.c:3383 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x8 ---truncated---

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.