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

schedext: Fix starvation of scxenable() under fair-class saturation

During scxenable(), the READY -> ENABLED task switching loop changes the calling thread's schedclass from fair to ext. Since fair has higher priority than ext, saturating fair-class workloads can indefinitely starve the enable thread, hanging the system. This was introduced when the enable path switched from preemptdisable() to scxbypass() which doesn't protect against fair-class starvation. Note that the original preemptdisable() protection wasn't complete either - in partial switch modes, the calling thread could still be starved after preemptenable() as it may have been switched to ext class.

Fix it by offloading the enable body to a dedicated system-wide RT (SCHEDFIFO) kthread which cannot be starved by either fair or ext class tasks. scxenable() lazily creates the kthread on first use and passes the ops pointer through a struct scxenablecmd containing the kthreadwork, then synchronously waits for completion.

The workfn runs on a different kthread from sch->helper (which runs disablework), so it can safely flush disablework on the error path without deadlock.

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

drm/mediatek: Fix potential NULL dereference in mtkcrtcdestroy()

In mtkcrtccreate(), if the call to mboxrequestchannel() fails then we set the "mtkcrtc->cmdqclient.chan" pointer to NULL. In that situation, we do not call cmdqpktcreate().

During the cleanup, we need to check if the "mtkcrtc->cmdqclient.chan" is NULL first before calling cmdqpktdestroy(). Calling cmdqpktdestroy() is unnecessary if we didn't call cmdqpktcreate() and it will result in a NULL pointer dereference.

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

NFSD: Initialize struct nfsd4copy earlier

Ensure the refcount and asynccopies fields are initialized early. cleanupasynccopy() will reference these fields if an error occurs in nfsd4copy(). If they are not correctly initialized, at the very least, a refcount underflow occurs.

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

ksmbd: check outstanding simultaneous SMB operations

If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbdworkcache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.

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

net: enetc: allocate vfstate during PF probes

In the previous implementation, vfstate is allocated memory only when VF is enabled. However, netdeviceops::ndosetvfmac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetcpfsetvfmac() will access vfstate, resulting in access to a null pointer. The simplified error log is as follows.

root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetcpfsetvfmac+0x3c/0x80 Message from sy [ 173.641973] lr : dosetlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetcpfsetvfmac+0x3c/0x80 [ 173.738847] rtnlnewlink+0x530/0x89c [ 173.742692] rtnlnewlink+0x50/0x7c [ 173.746189] rtnetlinkrcvmsg+0x128/0x390 [ 173.750298] netlinkrcvskb+0x60/0x130 [ 173.754145] rtnetlinkrcv+0x18/0x24 [ 173.757731] netlinkunicast+0x318/0x380 [ 173.761665] netlinksendmsg+0x17c/0x3c8

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

ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnelfind()

The per-netns IP tunnel hash table is protected by the RTNL mutex and iptunnelfind() is only called from the control path where the mutex is taken.

Add a lockdep expression to hlistforeachentryrcu() in iptunnelfind() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1].

[1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/iptunnel.c:221 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60

stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 iptunnelfind+0x435/0x4d0 iptunnelnewlink+0x517/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 syssendmsg+0x8f9/0xc20 syssendmsg+0x197/0x1e0 syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

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

nvme-multipath: defer partition scanning

We need to suppress the partition scan from occuring within the controller's scanwork context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scanwork, so it would deadlock. Defer the partion scan to a different context that does not block scanwork.

fsl/fman: Fix refcount handling of fman-related devices

btrfs: reinitialize delayed ref list after deleting it from the list

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

ksmbd: Fix the missing xastore error check

xastore() can fail, it return xaerr(-EINVAL) if the entry cannot be stored in an XArray, or xaerr(-ENOMEM) if memory allocation failed, so check error for xastore() to fix it.

drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported

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

nfsd: fix race between laundromat and freestateid

There is a race between laundromat handling of revoked delegations and a client sending freestateid operation. Laundromat thread finds that delegation has expired and needs to be revoked so it marks the delegation stid revoked and it puts it on a reaper list but then it unlock the state lock and the actual delegation revocation happens without the lock. Once the stid is marked revoked a racing freestateid processing thread does the following (1) it calls listdelinit() which removes it from the reaper list and (2) frees the delegation stid structure. The laundromat thread ends up not calling the revokedelegation() function for this particular delegation but that means it will no release the lock lease that exists on the file.

Now, a new open for this file comes in and ends up finding that lease list isn't empty and calls nfsdbreakerownslease() which ends up trying to derefence a freed delegation stateid. Leading to the followint use-after-free KASAN warning:

kernel: ================================================================== kernel: BUG: KASAN: slab-use-after-free in nfsdbreakerownslease+0x140/0x160 [nfsd] kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205 kernel: kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9 kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024 kernel: Call trace: kernel: dumpbacktrace+0x98/0x120 kernel: showstack+0x1c/0x30 kernel: dumpstacklvl+0x80/0xe8 kernel: printaddressdescription.constprop.0+0x84/0x390 kernel: printreport+0xa4/0x268 kernel: kasanreport+0xb4/0xf8 kernel: asanreportload8noabort+0x1c/0x28 kernel: nfsdbreakerownslease+0x140/0x160 [nfsd] kernel: nfsdfiledoacquire+0xb3c/0x11d0 [nfsd] kernel: nfsdfileacquireopened+0x84/0x110 [nfsd] kernel: nfs4getvfsfile+0x634/0x958 [nfsd] kernel: nfsd4processopen2+0xa40/0x1a40 [nfsd] kernel: nfsd4open+0xa08/0xe80 [nfsd] kernel: nfsd4proccompound+0xb8c/0x2130 [nfsd] kernel: nfsddispatch+0x22c/0x718 [nfsd] kernel: svcprocesscommon+0x8e8/0x1960 [sunrpc] kernel: svcprocess+0x3d4/0x7e0 [sunrpc] kernel: svchandlexprt+0x828/0xe10 [sunrpc] kernel: svcrecv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd] kernel: kthread+0x288/0x310 kernel: retfromfork+0x10/0x20

This patch proposes a fixed that's based on adding 2 new additional stid's scstatus values that help coordinate between the laundromat and other operations (nfsd4freestateid() and nfsd4delegreturn()).

First to make sure, that once the stid is marked revoked, it is not removed by the nfsd4freestateid(), the laundromat take a reference on the stateid. Then, coordinating whether the stid has been put on the clrevoked list or we are processing FREESTATEID and need to make sure to remove it from the list, each check that state and act accordingly. If laundromat has added to the clrevoke list before the arrival of FREESTATEID, then nfsd4freestateid() knows to remove it from the list. If nfsd4freestateid() finds that operations arrived before laundromat has placed it on clrevoke list, it marks the state freed and then laundromat will no longer add it to the list.

Also, for nfsd4delegreturn() when looking for the specified stid, we need to access stid that are marked removed or freeable, it means the laundromat has started processing it but hasn't finished and this delegreturn needs to return nfserrdelegrevoked and not nfserrbadstateid. The latter will not trigger a FREESTATEID and the lack of it will leave this stid on the clrevoked list indefinitely.

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

net/mlx5e: Don't call cleanup on profile rollback failure

When profile rollback fails in mlx5enetdevchangeprofile, the netdev profile var is left set to NULL. Avoid a crash when unloading the driver by not calling profile->cleanup in such a case.

This was encountered while testing, with the original trigger that the wq rescuer thread creation got interrupted (presumably due to Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by mlx5eprivinit, the profile rollback also fails for the same reason (signal still active) so the profile is left as NULL, leading to a crash later in mlx5eremove.

[ 732.473932] mlx5core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2) [ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.557372] mlx5core 0000:08:00.1: mlx5enetdevinitprofile:6235:(pid 6086): mlx5eprivinit failed, err=-12 [ 734.559187] mlx5core 0000:08:00.1 eth3: mlx5enetdevchangeprofile: new profile init failed, -12 [ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.589378] mlx5core 0000:08:00.1: mlx5enetdevinitprofile:6235:(pid 6086): mlx5eprivinit failed, err=-12 [ 734.591136] mlx5core 0000:08:00.1 eth3: mlx5enetdevchangeprofile: failed to rollback to orig profile, -12 [ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 745.538222] #PF: supervisor read access in kernel mode <snipped> [ 745.551290] Call Trace: [ 745.551590] <TASK> [ 745.551866] ? die+0x20/0x60 [ 745.552218] ? pagefaultoops+0x150/0x400 [ 745.555307] ? excpagefault+0x79/0x240 [ 745.555729] ? asmexcpagefault+0x22/0x30 [ 745.556166] ? mlx5eremove+0x6b/0xb0 [mlx5core] [ 745.556698] auxiliarybusremove+0x18/0x30 [ 745.557134] devicereleasedriverinternal+0x1df/0x240 [ 745.557654] busremovedevice+0xd7/0x140 [ 745.558075] devicedel+0x15b/0x3c0 [ 745.558456] mlx5rescandriverslocked.part.0+0xb1/0x2f0 [mlx5core] [ 745.559112] mlx5unregisterdevice+0x34/0x50 [mlx5core] [ 745.559686] mlx5uninitone+0x46/0xf0 [mlx5core] [ 745.560203] removeone+0x4e/0xd0 [mlx5core] [ 745.560694] pcideviceremove+0x39/0xa0 [ 745.561112] devicereleasedriverinternal+0x1df/0x240 [ 745.561631] driverdetach+0x47/0x90 [ 745.562022] busremovedriver+0x84/0x100 [ 745.562444] pciunregisterdriver+0x3b/0x90 [ 745.562890] mlx5cleanup+0xc/0x1b [mlx5core] [ 745.563415] x64sysdeletemodule+0x14d/0x2f0 [ 745.563886] ? kmemcachefree+0x1b0/0x460 [ 745.564313] ? lockdephardirqsonprepare+0xe2/0x190 [ 745.564825] dosyscall64+0x6d/0x140 [ 745.565223] entrySYSCALL64afterhwframe+0x4b/0x53 [ 745.565725] RIP: 0033:0x7f1579b1288b

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

xhci: tegra: fix checked USB2 port number

If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller.

Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access.

[ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegraxusbenterelpg+0x23c/0x658 [ 117.222021] tegraxusbruntimesuspend+0x40/0x68 [ 117.227260] pmgenericruntimesuspend+0x30/0x50 [ 117.232847] rpmcallback+0x84/0x3c0 [ 117.237038] rpmsuspend+0x2dc/0x740 [ 117.241229] pmruntimework+0xa0/0xb8 [ 117.245769] processscheduledworks+0x24c/0x478 [ 117.251007] workerthread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] retfromfork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)

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

x86: fix user address masking non-canonical speculation issue

It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:

CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“

Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.

But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.

Note that this affects not just the new address masking, but also the regular validuseraddress() check used by accessok(), and the asm version of the sign bit check in the getuser() helpers.

It does not affect putuser() or clearuser() variants, since there's no speculative result to be used in a gadget for those operations.

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

ksmbd: fix slab-use-after-free in ksmbdsmb2sessioncreate

There is a race condition between ksmbdsmb2sessioncreate and ksmbdexpiresession. This patch add missing sessionstablelock while adding/deleting session from global session table.

Bluetooth: hcicore: Disable works on hciunregisterdev

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

netfilter: bpf: must hold reference on net namespace

BUG: KASAN: slab-use-after-free in nfunregisternethook+0x640/0x6b0 Read of size 8 at addr ffff8880106fe400 by task repro/72= bpfnflinkrelease+0xda/0x1e0 bpflinkfree+0x139/0x2d0 bpflinkrelease+0x68/0x80 fput+0x414/0xb60

Eric says: It seems that bpf was able to defer the nfunregisternethook() after exit()/close() time. Perhaps a netns reference is missing, because the netns has been dismantled/freed already. bpfnflinkattach() does : link->net = net; But I do not see a reference being taken on net.

Add such a reference and release it after hook unreg. Note that I was unable to get syzbot reproducer to work, so I do not know if this resolves this splat.

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

net: fix data-races around sk->skforwardalloc

Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/afinet.c:156 inetsockdestruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn+0x88/0x130 ? inetsockdestruct+0x1c5/0x1e0 ? reportbug+0x18e/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x1c5/0x1e0 skdestruct+0x2a/0x200 rcudobatch+0x1aa/0x530 ? rcudobatch+0x13b/0x530 rcucore+0x159/0x2f0 handlesoftirqs+0xd3/0x2b0 ? pfxsmpbootthreadfn+0x10/0x10 runksoftirqd+0x25/0x30 smpbootthreadfn+0xdd/0x1d0 kthread+0xd3/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---

Its possible that two threads call tcpv6dorcv()/skforwardallocadd() concurrently when sk->skstate == TCPLISTEN with sk->sklock unlocked, which triggers a data-race around sk->skforwardalloc: tcpv6rcv tcpv6dorcv skbcloneandcharger skrmemschedule skmemschedule skforwardallocadd() skbsetownerr skmemcharge skforwardallocadd() kfreeskb skbreleaseall skbreleaseheadstate sockrfree skmemuncharge skforwardallocadd() skmemreclaim // set local var reclaimable skmemreclaim skforwardallocadd()

In this syzkaller testcase, two threads call tcpv6dorcv() with skb->truesize=768, the skforwardalloc changes like this: (cpu 1) | (cpu 2) | skforwardalloc ... | ... | 0 skmemschedule() | | +4096 = 4096 | skmemschedule() | +4096 = 8192 skmemcharge() | | -768 = 7424 | skmemcharge() | -768 = 6656 ... | ... | skmemuncharge() | | +768 = 7424 reclaimable=7424 | | | skmemuncharge() | +768 = 8192 | reclaimable=8192 | skmemreclaim() | | -4096 = 4096 | skmemreclaim() | -8192 = -4096 != 0

The skbcloneandcharger() should not be called in tcpv6dorcv() when sk->skstate is TCPLISTEN, it happens later in tcpv6synrecvsock(). Fix the same issue in dccpv6dorcv().

bpf: Fix overloading of MEMUNINIT's meaning

HID: core: zero-initialize the report buffer

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

vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans

During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.

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:

net/sched: stop qdisctreereducebacklog on TCHROOT

In qdisctreereducebacklog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer.

In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TCHROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisclookup with TCHMAJ(TCHROOT).

In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TCHROOT, which then the iteration must stop.

net/sched/schapi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

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

hvsock: Initializing vsk->trans to NULL to prevent a dangling pointer

When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.

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

posix-clock: Fix missing timespec64 check in pcclocksettime()

As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tvsec and tvnsec range before calling ptp->info->settime64().

As the man manual of clocksettime() said, if tp.tvsec is negative or tp.tvnsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64valid(). As Thomas suggested, timespec64valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64validstrict() in pcclocksettime() and return -EINVAL if not valid.

There are some drivers that use tp->tvsec and tp->tvnsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclgeptpsettime(), igbptpsettimei210(), rcargen4ptpsettime(), and some drivers can remove the checks of itself.

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

nilfs2: propagate directory read errors from nilfsfindentry()

Syzbot reported that a task hang occurs in vcsopen() during a fuzzing test for nilfs2.

The root cause of this problem is that in nilfsfindentry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfsgetfolio() fails.

If the filesystem images is corrupted, and the isize of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfscheckfolio() may continue to spit out error messages in bursts.

Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfsfindentry().

The current interface of nilfsfindentry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfsfindentry(), so fix it together.

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

mm/swapfile: skip HugeTLB pages for unusevma

I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps:

1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message:

mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)

We can tell that pudclearbad is called by pudnoneorclearbad in unusepudrange() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unusevma to fix it.

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

pinctrl: ocelot: fix system hang on level based interrupts

The current implementation only calls chainedirqenter() and chainedirqexit() if it detects pending interrupts.

for (i = 0; i < info->stride; i++) { uregmapread(info->map, idreg + 4 i, &reg); if (!reg) continue;

chainedirqenter(parentchip, desc);

However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chainedirqenter() never gets called and the system hangs trying to service the parent interrupt.

Moving chainedirqenter() and chainedirqexit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware.

The similar code with chainedirqenter() / chainedirqexit() functions wrapping interrupt checking loop may be found in many other drivers: grep -r -A 10 chainedirqenter drivers/pinctrl

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

netfilter: nfrejectipv6: fix potential crash in nfsendreset6()

I got a syzbot report without a repro [1] crashing in nfsendreset6()

I think the issue is that dev->hardheaderlen is zero, and we attempt later to push an Ethernet header.

Use LLMAXHEADER, as other functions in net/ipv6/netfilter/nfrejectipv6.c.

[1]

skbuff: skbunderpanic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syztun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skbpanic net/core/skbuff.c:206 [inline] RIP: 0010:skbunderpanic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpush+0xe5/0x100 net/core/skbuff.c:2636 ethheader+0x38/0x1f0 net/ethernet/eth.c:83 devhardheader include/linux/netdevice.h:3208 [inline] nfsendreset6+0xce6/0x1270 net/ipv6/netfilter/nfrejectipv6.c:358 nftrejectineteval+0x3b9/0x690 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x4ad/0x1da0 net/netfilter/nftablescore.c:288 nftdochaininet+0x418/0x6b0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xc3/0x220 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] brnfpreroutingipv6+0x63e/0x770 net/bridge/brnetfilteripv6.c:184 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookbridgepre net/bridge/brinput.c:277 [inline] brhandleframe+0x9fd/0x1530 net/bridge/brinput.c:424 netifreceiveskbcore+0x13e8/0x4570 net/core/dev.c:5562 netifreceiveskbonecore net/core/dev.c:5666 [inline] netifreceiveskb+0x12f/0x650 net/core/dev.c:5781 netifreceiveskbinternal net/core/dev.c:5867 [inline] netifreceiveskb+0x1e8/0x890 net/core/dev.c:5926 tunrxbatched+0x1b7/0x8f0 drivers/net/tun.c:1550 tungetuser+0x3056/0x47e0 drivers/net/tun.c:2007 tunchrwriteiter+0x10d/0x1f0 drivers/net/tun.c:2053 newsyncwrite fs/readwrite.c:590 [inline] vfswrite+0xa6d/0xc90 fs/readwrite.c:683 ksyswrite+0x183/0x2b0 fs/readwrite.c:736 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---