cgroup: split cgroupdestroywq into 3 workqueues

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

jbd2: prevent softlockup in jbd2logdocheckpoint()

Both jbd2logdocheckpoint() and jbd2journalshrinkcheckpointlist() periodically release jlistlock after processing a batch of buffers to avoid long hold times on the jlistlock. However, since both functions contend for jlistlock, the combined time spent waiting and processing can be significant.

jbd2journalshrinkcheckpointlist() explicitly calls condresched() when needresched() is true to avoid softlockups during prolonged operations. But jbd2logdocheckpoint() only exits its loop when needresched() is true, relying on potentially sleeping functions like flushbatch() or waitonbuffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup.

watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wbworkfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nativequeuedspinlockslowpath+0x358/0x418 lr : jbd2logdocheckpoint+0x31c/0x438 [jbd2] Call trace: nativequeuedspinlockslowpath+0x358/0x418 jbd2logdocheckpoint+0x31c/0x438 [jbd2] jbd2logwaitforspace+0xfc/0x2f8 [jbd2] addtransactioncredits+0x3bc/0x418 [jbd2] startthishandle+0xf8/0x560 [jbd2] jbd2journalstart+0x118/0x228 [jbd2] ext4journalstartsb+0x110/0x188 [ext4] ext4dowritepages+0x3dc/0x740 [ext4] ext4writepages+0xa4/0x190 [ext4] dowritepages+0x94/0x228 writebacksingleinode+0x48/0x318 writebacksbinodes+0x204/0x590 writebackinodeswb+0x54/0xf8 wbwriteback+0x2cc/0x3d8 wbdowriteback+0x2e0/0x2f8 wbworkfn+0x80/0x2a8 processonework+0x178/0x3e8 workerthread+0x234/0x3b8 kthread+0xf0/0x108 retfromfork+0x10/0x20

So explicitly call condresched() in jbd2logdocheckpoint() to avoid softlockup.

fs: Prevent file descriptor table allocations exceeding INTMAX

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

net: lan743x: Fix memleak issue when GSO enabled

Always map the skb to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak

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

thermal: int340x: Add NULL check for adev

Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL").

Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402thermalprobe().

Note, under the same directory, int3400thermalprobe() has such a check.

[ rjw: Subject edit, added Fixes: ]

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

net: Fix null-ptr-deref by socklockinitclassandname() and rmmod.

When I ran the repro [0] and waited a few seconds, I observed two LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]

Reproduction Steps:

1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables rule

At step 3), the CIFS module calls sockrelease() for the underlying TCP socket, and it returns quickly. However, the socket remains in FINWAIT1 because incoming FIN packets are dropped.

At this point, the module's refcnt is 0 while the socket is still alive, so the following rmmod command succeeds.

# ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445

# lsmod | grep cifs cifs 1159168 0

This highlights a discrepancy between the lifetime of the CIFS module and the underlying TCP socket. Even after CIFS calls sockrelease() and it returns, the TCP socket does not die immediately in order to close the connection gracefully.

While this is generally fine, it causes an issue with LOCKDEP because CIFS assigns a different lock class to the TCP socket's sk->sklock using socklockinitclassandname().

Once an incoming packet is processed for the socket or a timer fires, sk->sklock is acquired.

Then, LOCKDEP checks the lock context in checkwaitcontext(), where hlockclass() is called to retrieve the lock class. However, since the module has already been unloaded, hlockclass() logs a warning and returns NULL, triggering the null-ptr-deref.

If LOCKDEP is enabled, we must ensure that a module calling socklockinitclassandname() (CIFS, NFS, etc) cannot be unloaded while such a socket is still alive to prevent this issue.

Let's hold the module reference in socklockinitclassandname() and release it when the socket is freed in skprotfree().

Note that socklockinit() clears sk->skowner for svccreatesocket() that calls socklockinitclassandname() for a listening socket, which clones a socket by skclonelock() without GFPZERO.

[0]: CIFSSERVER="10.0.0.137" CIFSPATH="//${CIFSSERVER}/Users/Administrator/Desktop/CIFSTEST" DEV="enp0s3" CRED="/root/WindowsCredential.txt"

MNT=$(mktemp -d /tmp/XXXXXX) mount -t cifs ${CIFSPATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echointerval=1

iptables -A INPUT -s ${CIFSSERVER} -j DROP

for i in $(seq 10); do umount ${MNT} rmmod cifs sleep 1 done

rm -r ${MNT}

iptables -D INPUT -s ${CIFSSERVER} -j DROP

[1]: DEBUGLOCKSWARNON(1) WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) Modules linked in: cifsarc4 nlsucs2utils cifsmd4 [last unloaded: cifs] CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:hlockclass (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223) ... Call Trace: <IRQ> lockacquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lockacquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) rawspinlocknested (kernel/locking/spinlock.c:379) tcpv4rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcpipv4.c:2350) ...

BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present page PGD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:lockacquire (kernel/ ---truncated---

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

ipv6: Fix memleak of nhcpcpurthoutput in fibchecknhv6gw().

fibchecknhv6gw() expects that fib6nhinit() cleans up everything when it fails.

Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6nh") moved fibnhcommoninit() before allocpercpugfp() within fib6nhinit() but forgot to add cleanup for fib6nh->nhcommon.nhcpcpurthoutput in case it fails to allocate fib6nh->rt6ipcpu, resulting in memleak.

Let's call fibnhcommonrelease() and clear nhcpcpurthoutput in the error path.

Note that we can remove the fib6nhrelease() call in nhcreateipv6() later in net-next.git.

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

llc: do not use skbget() before devqueuexmit()

syzbot is able to crash hosts [1], using llc and devices not supporting IFFTXSKBSHARING.

In this case, e1000 driver calls ethskbpad(), while the skb is shared.

Simply replace skbget() by skbclone() in net/llc/llcsac.c

Note that e1000 driver might have an issue with pktgen, because it does not clear IFFTXSKBSHARING, this is an orthogonal change.

We need to audit other skbget() uses in net/llc.

[1]

kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskbexpandhead+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> skbpad+0x18a/0x610 net/core/skbuff.c:2466 skbputpadto include/linux/skbuff.h:3843 [inline] skbputpadto include/linux/skbuff.h:3862 [inline] ethskbpad include/linux/etherdevice.h:656 [inline] e1000xmitframe+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000main.c:3128 netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3806 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3822 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 devxmitskb net/core/dev.c:4045 [inline] devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4621 devqueuexmit include/linux/netdevice.h:3313 [inline] llcsapactionsendtestc+0x268/0x320 net/llc/llcsac.c:144 llcexecsaptransactions net/llc/llcsap.c:153 [inline] llcsapnextstate net/llc/llcsap.c:182 [inline] llcsapstateprocess+0x239/0x510 net/llc/llcsap.c:209 llcuisendmsg+0xd0d/0x14e0 net/llc/afllc.c:993 socksendmsgnosec net/socket.c:718 [inline]

bpf: avoid holding freezemutex during mmap operation

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

usb: gadget: fmidi: fix MIDI Streaming descriptor lengths

While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.

This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller.

The precise meaning of "in" and "out" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that "in" ports send data to the host and "out" ports receive data from it.

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

net: let net.core.devweight always be non-zero

The following problem was encountered during stability test:

(NULL netdevice): NAPI poll function processbacklog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ listadd double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/listdebug.c:35 \ listaddvalidorreport+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:listaddvalidorreport+0xf3/0x130 Call Trace: ? warn+0xcd/0x250 ? listaddvalidorreport+0xf3/0x130 enqueuetobacklog+0x923/0x1070 netifrxinternal+0x92/0x2b0 netifrx+0x15/0x170 loopbackxmit+0x2ef/0x450 devhardstartxmit+0x103/0x490 devqueuexmit+0xeac/0x1950 ipfinishoutput2+0x6cc/0x1620 ipoutput+0x161/0x270 ippushpendingframes+0x155/0x1a0 rawsendmsg+0xe13/0x1550 syssendto+0x3bf/0x4e0 x64syssendto+0xdc/0x1b0 dosyscall64+0x5b/0x170 entrySYSCALL64afterhwframe+0x76/0x7e

The reproduction command is as follows: sysctl -w net.core.devweight=0 ping 127.0.0.1

This is because when the napi's weight is set to 0, processbacklog() may return 0 and clear the NAPISTATESCHED bit of napi->state, causing this napi to be re-polled in netrxaction() until dosoftirq() times out. Since the NAPISTATESCHED bit has been cleared, napischedulerps() can be retriggered in enqueuetobacklog(), causing this issue.

Making the napi's weight always non-zero solves this problem.

Triggering this issue requires system-wide admin (setting is not namespaced).

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

net: usb: rtl8150: enable basic endpoint checking

Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below.

For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary.

[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usbsubmiturb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usbsubmiturb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rtl8150open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 devopen+0x2d4/0x4e0 net/core/dev.c:1474 devchangeflags+0x561/0x720 net/core/dev.c:8838 devchangeflags+0x8f/0x160 net/core/dev.c:8910 devinetioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inetioctl+0x3aa/0x3f0 net/ipv4/afinet.c:1003 sockdoioctl+0x116/0x280 net/socket.c:1222 sockioctl+0x22e/0x6c0 net/socket.c:1341 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:907 [inline] sesysioctl fs/ioctl.c:893 [inline] x64sysioctl+0x193/0x220 fs/ioctl.c:893 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ...

This change has not been tested on real hardware.

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

tomoyo: don't emit warning in tomoyowritecontrol()

syzbot is reporting too large allocation warning at tomoyowritecontrol(), for one can write a very very long line without new line character. To fix this warning, I use GFPNOWARN rather than checking for KMALLOCMAXSIZE, for practically a valid line should be always shorter than 32KB where the "too small to fail" memory-allocation rule applies.

One might try to write a valid line that is longer than 32KB, but such request will likely fail with -ENOMEM. Therefore, I feel that separately returning -EINVAL when a line is longer than KMALLOCMAXSIZE is redundant. There is no need to distinguish over-32KB and over-KMALLOCMAXSIZE.

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

team: prevent adding a device which is already a team device lower

Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1.

This is not useful in practice and can lead to recursive locking:

$ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0

============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->teamlockkey){+.+.}-{4:4}, at: teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973)

but task is already holding lock: ffff888016848e00 (team->teamlockkey){+.+.}-{4:4}, at: teamaddslave (drivers/net/team/teamcore.c:1147 drivers/net/team/teamcore.c:1977)

other info that might help us debug this: Possible unsafe locking scenario:

CPU0 ---- lock(team->teamlockkey); lock(team->teamlockkey);

DEADLOCK

May be due to missing lock nesting notation

2 locks held by ip/7684:

stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:122) printdeadlockbug.cold (kernel/locking/lockdep.c:3040) lockacquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlinkbroadcastfiltered (net/netlink/afnetlink.c:1548) lockacquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? tracelockacquire (./include/trace/events/lock.h:24 (discriminator 2)) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? lockacquire (kernel/locking/lockdep.c:5822) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) mutexlock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) ? fibsyncup (net/ipv4/fibsemantics.c:2167) ? teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) teamdeviceevent (drivers/net/team/teamcore.c:2928 drivers/net/team/teamcore.c:2951 drivers/net/team/teamcore.c:2973) notifiercallchain (kernel/notifier.c:85) callnetdevicenotifiersinfo (net/core/dev.c:1996) devnotifyflags (net/core/dev.c:8993) ? devchangeflags (net/core/dev.c:8975) devchangeflags (net/core/dev.c:9027) vlandeviceevent (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? brdeviceevent (net/bridge/br.c:143) notifiercallchain (kernel/notifier.c:85) callnetdevicenotifiersinfo (net/core/dev.c:1996) devopen (net/core/dev.c:1519 net/core/dev.c:1505) teamaddslave (drivers/net/team/teamcore.c:1219 drivers/net/team/teamcore.c:1977) ? pfxteamaddslave (drivers/net/team/teamcore.c:1972) dosetmaster (net/core/rtnetlink.c:2917) dosetlink.isra.0 (net/core/rtnetlink.c:3117)

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

ipmi: ipmb: Add check devmkasprintf() returned value

devmkasprintf() can return a NULL pointer on failure but this returned value is not checked.

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

wifi: rtlwifi: fix memory leaks and invalid access at probe error path

Deinitialize at reverse order when probe fails.

When initswvars fails, rtldeinitcore should not be called, specially now that it destroys the rtlwq workqueue.

And call rtlpcideinit and deinitswvars, otherwise, memory will be leaked.

Remove pcisetdrvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pcisetdrvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").

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

ubifs: skip dumping tnc tree when zroot is null

Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference.

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

mac802154: check local interfaces before deleting sdata list

syzkaller reported a corrupted list in ieee802154ifremove. [1]

Remove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4 hardware device from the system.

CPU0 CPU1 ==== ==== genlfamilyrcvmsgdoit ieee802154unregisterhw ieee802154deliface ieee802154removeinterfaces rdevdelvirtualintfdeprecated listdel(&sdata->list) ieee802154ifremove listdelrcu

The net device has been unregistered, since the rcu grace period, unregistration must be run before ieee802154ifremove.

To avoid this issue, add a check for local->interfaces before deleting sdata list.

[1] kernel BUG at lib/listdebug.c:58! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:listdelentryvalidorreport+0xf4/0x140 lib/listdebug.c:56 Code: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 <0f> 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7 RSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246 RAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d R10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000 R13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0 FS: 0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> listdelentryvalid include/linux/list.h:124 [inline] listdelentry include/linux/list.h:215 [inline] listdelrcu include/linux/rculist.h:157 [inline] ieee802154ifremove+0x86/0x1e0 net/mac802154/iface.c:687 rdevdelvirtualintfdeprecated net/ieee802154/rdev-ops.h:24 [inline] ieee802154deliface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323 genlfamilyrcvmsgdoit net/netlink/genetlink.c:1115 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlinkrcvskb+0x1e3/0x430 net/netlink/afnetlink.c:2551 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0x7f6/0x990 net/netlink/afnetlink.c:1357 netlinksendmsg+0x8e4/0xcb0 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:729 [inline] socksendmsg+0x221/0x270 net/socket.c:744 syssendmsg+0x52a/0x7e0 net/socket.c:2607 syssendmsg net/socket.c:2661 [inline] syssendmsg+0x292/0x380 net/socket.c:2690 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

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

usb: gadget: ffs: Remove WARNON in functionfsbind

This commit addresses an issue related to below kernel panic where paniconwarn is enabled. It is caused by the unnecessary use of WARNON in functionsfsbind, which easily leads to the following scenarios.

1.adbwrite in adbd 2. UDC write via configfs ================= =====================

->usbffsopenthread() ->UDC write ->openfunctionfs() ->configfswriteiter() ->adbopen() ->gadgetdevdescUDCstore() ->adbwrite() ->usbgadgetregisterdriverowner ->driverregister() ->StartMonitor() ->busadddriver() ->adbread() ->gadgetbinddriver() <times-out without BIND event> ->configfscompositebind() ->usbaddfunction() ->openfunctionfs() ->ffsfuncbind() ->adbopen() ->functionfsbind() <ffs->state !=FFSACTIVE>

The adbopen, adbread, and adbwrite operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARNON from functionfsbind when paniconwarn is enabled. This commit fixes the kernel panic by removing the unnecessary WARNON.

Kernel panic - not syncing: kernel: paniconwarn set ... [ 14.542395] Call trace: [ 14.542464] ffsfuncbind+0x1c8/0x14a8 [ 14.542468] usbaddfunction+0xcc/0x1f0 [ 14.542473] configfscompositebind+0x468/0x588 [ 14.542478] gadgetbinddriver+0x108/0x27c [ 14.542483] reallyprobe+0x190/0x374 [ 14.542488] driverprobedevice+0xa0/0x12c [ 14.542492] driverprobedevice+0x3c/0x220 [ 14.542498] driverattach+0x11c/0x1fc [ 14.542502] busforeachdev+0x104/0x160 [ 14.542506] driverattach+0x24/0x34 [ 14.542510] busadddriver+0x154/0x270 [ 14.542514] driverregister+0x68/0x104 [ 14.542518] usbgadgetregisterdriverowner+0x48/0xf4 [ 14.542523] gadgetdevdescUDCstore+0xf8/0x144 [ 14.542526] configfswriteiter+0xf0/0x138

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

mm: vmscan: account for free pages to prevent infinite Loop in throttledirectreclaim()

The task sometimes continues looping in throttledirectreclaim() because allowdirectreclaim(pgdat) keeps returning false.

#0 [ffff80002cb6f8d0] switchto at ffff8000080095ac #1 [ffff80002cb6f900] schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttledirectreclaim at ffff800008273550 #4 [ffff80002cb6fa20] trytofreepages at ffff800008277b68 #5 [ffff80002cb6fae0] allocpagesnodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] allocpagesvma at ffff8000082e4a98 #7 [ffff80002cb6fca0] doanonymouspage at ffff80000829f5a8 #8 [ffff80002cb6fce0] handlemmfault at ffff8000082a5974 #9 [ffff80002cb6fd90] handlemmfault at ffff8000082a5bd4

At this point, the pgdat contains the following two zones:

NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VMSTAT: NRFREEPAGES: 359 NRZONEINACTIVEANON: 18813 NRZONEACTIVEANON: 0 NRZONEINACTIVEFILE: 50 NRZONEACTIVEFILE: 0 NRZONEUNEVICTABLE: 0 NRZONEWRITEPENDING: 0 NRMLOCK: 0 NRBOUNCE: 0 NRZSPAGES: 0 NRFREECMAPAGES: 0

NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VMSTAT: NRFREEPAGES: 146 NRZONEINACTIVEANON: 94668 NRZONEACTIVEANON: 3 NRZONEINACTIVEFILE: 735 NRZONEACTIVEFILE: 78 NRZONEUNEVICTABLE: 0 NRZONEWRITEPENDING: 0 NRMLOCK: 0 NRBOUNCE: 0 NRZSPAGES: 0 NRFREECMAPAGES: 0

In allowdirectreclaim(), while processing ZONEDMA32, the sum of inactive/active file-backed pages calculated in zonereclaimablepages() based on the result of zonepagestatesnapshot() is zero.

Additionally, since this system lacks swap, the calculation of inactive/ active anonymous pages is skipped.

crash&gt; p nrswappages nrswappages = $1937 = { counter = 0 }

As a result, ZONEDMA32 is deemed unreclaimable and skipped, moving on to the processing of the next zone, ZONENORMAL, despite ZONEDMA32 having free pages significantly exceeding the high watermark.

The problem is that the pgdat-&gt;kswapdfailures hasn't been incremented.

crash&gt; px ((struct pglistdata ) 0xffff00817fffe540)-&gt;kswapdfailures $1935 = 0x0

This is because the node deemed balanced. The node balancing logic in balancepgdat() evaluates all zones collectively. If one or more zones (e.g., ZONEDMA32) have enough free pages to meet their watermarks, the entire node is deemed balanced. This causes balancepgdat() to exit early before incrementing the kswapdfailures, as it considers the overall memory state acceptable, even though some zones (like ZONENORMAL) remain under significant pressure.

The patch ensures that zonereclaimablepages() includes free pages (NRFREEPAGES) in its calculation when no other reclaimable pages are available (e.g., file-backed or anonymous pages). This change prevents zones like ZONEDMA32, which have sufficient free pages, from being mistakenly deemed unreclaimable. By doing so, the patch ensures proper node balancing, avoids masking pressure on other zones like ZONENORMAL, and prevents infinite loops in throttledirectreclaim() caused by allowdirectreclaim(pgdat) repeatedly returning false.

The kernel hangs due to a task stuck in throttledirectreclaim(), caused by a node being incorrectly deemed balanced despite pressure in certain zones, such as ZONENORMAL. This issue arises from zonereclaimablepages ---truncated---

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

net/sched: netem: account for backlog updates from child qdisc

In general, 'qlen' of any classful qdisc should keep track of the number of packets that the qdisc itself and all of its children holds. In case of netem, 'qlen' only accounts for the packets in its internal tfifo. When netem is used with a child qdisc, the child qdisc can use 'qdisctreereducebacklog' to inform its parent, netem, about created or dropped SKBs. This function updates 'qlen' and the backlog statistics of netem, but netem does not account for changes made by a child qdisc. 'qlen' then indicates the wrong number of packets in the tfifo. If a child qdisc creates new SKBs during enqueue and informs its parent about this, netem's 'qlen' value is increased. When netem dequeues the newly created SKBs from the child, the 'qlen' in netem is not updated. If 'qlen' reaches the configured sch->limit, the enqueue function stops working, even though the tfifo is not full.

Reproduce the bug: Ensure that the sender machine has GSO enabled. Configure netem as root qdisc and tbf as its child on the outgoing interface of the machine as follows: $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100 $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms

Send bulk TCP traffic out via this interface, e.g., by running an iPerf3 client on the machine. Check the qdisc statistics: $ tc -s qdisc show dev <oif>

Statistics after 10s of iPerf3 TCP test before the fix (note that netem's backlog > limit, netem stopped accepting packets): qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0

Statistics after the fix: qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0

tbf segments the GSO SKBs (tbfsegment) and updates the netem's 'qlen'. The interface fully stops transferring packets and "locks". In this case, the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at its limit and no more packets are accepted.

This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is only decreased when a packet is returned by its dequeue function, and not during enqueuing into the child qdisc. External updates to 'qlen' are thus accounted for and only the behavior of the backlog statistics changes. As in other qdiscs, 'qlen' then keeps track of how many packets are held in netem and all of its children. As before, sch->limit remains as the maximum number of packets in the tfifo. The same applies to netem's backlog statistics.

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

vsock/virtio: fix accept queue count leak on transport mismatch

virtiotransportrecvlisten() calls skacceptqadded() before vsockassigntransport(). If vsockassigntransport() fails or selects a different transport, the error path returns without calling skacceptqremoved(), permanently incrementing skackbacklog.

After approximately backlog+1 such failures, skacceptqisfull() returns true, causing the listener to reject all new connections.

Fix by moving skacceptqadded() to after the transport validation, matching the pattern used by vmcitransport and hypervtransport.

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

ftrace: Fix regression with module command in stacktracefilter

When executing the following command:

# echo "write:mod:ext3" > /sys/kernel/tracing/stacktracefilter

The current mod command causes a null pointer dereference. While commit 0f17976568b3f ("ftrace: Fix regression with module command in stacktracefilter") has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash.

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

fs: Fix uninitialized value issue in fromkuid and fromkgid

ocfs2setattr() uses attr->iamode, attr->iauid and attr->iagid in a trace point even though ATTRMODE, ATTRUID and ATTRGID aren't set.

Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTRMODE, ATTRUID, ATTRGID are initialized, otherwise 0.

HID: core: zero-initialize the report buffer

ALSA: firewire-lib: Avoid division by zero in applyconstrainttosize()

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

netfilter: nftpayload: sanitize offset and length before calling skbchecksum()

If access to offset + length is larger than the skbuff length, then skbchecksum() triggers BUGON().

skbchecksum() internally subtracts the length parameter while iterating over skbuff, BUGON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.

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

xfrm: validate new SA's prefixlen using SA family when sel.family is unset

This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.")

syzbot created an SA with usersa.sel.family = AFUNSPEC usersa.sel.prefixlens = 128 usersa.family = AFINET

Because of the AFUNSPEC selector, verifynewsainfo doesn't put limits on prefixlen{s,d}. But then copyfromuserstate sets x->sel.family to usersa.family (AFINET). Do the same conversion in verifynewsainfo before validating prefixlen{s,d}, since that's how prefixlen is going to be used later on.

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

Bluetooth: bnep: fix wild-memory-access in protounregister

There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:protounregister+0xee/0x400 Call Trace: <TASK> dosysdeletemodule+0x318/0x580 dosyscall64+0xc1/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

As bnepinit() ignore bnepsockinit()'s return value, and bnepsockinit() will cleanup all resource. Then when remove bnep module will call bnepsockcleanup() to cleanup sock's resource. To solve above issue just return bnepsockinit()'s return value in bnepexit().