block: avoid possible overflow for chunksectors check in blkstacklimits()

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

netfilter: nftsetpipapo: clamp maximum map bucket size to INTMAX

Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset.

Similar to:

b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INTMAX")

dmaengine: idxd: fix device leaks on compat bind and unbind

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

net: bridge: fix soft lockup in brmulticastqueryexpired()

When set multicastqueryinterval to a large value, the local variable 'time' in brmulticastsendquery() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call modtimer() again, which creates a loop and may trigger the following soft lockup issue.

watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rbconsumer:66] CPU: 1 UID: 0 PID: 66 Comm: rbconsumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: <IRQ> netdevallocskb+0x2e/0x3a0 brip6multicastallocquery+0x212/0x1b70 brmulticastsendquery+0x376/0xac0 brmulticastsendquery+0x299/0x510 brmulticastqueryexpired.constprop.0+0x16d/0x1b0 calltimerfn+0x3b/0x2a0 runtimers+0x619/0x950 runtimersoftirq+0x11c/0x220 handlesoftirqs+0x18e/0x560 irqexitrcu+0x158/0x1a0 sysvecapictimerinterrupt+0x76/0x90 </IRQ>

This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicastquerier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicastqueryinterval ip link set dev br0 up

The multicaststartupqueryinterval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.

block: fix resource leak in blkregisterqueue() error path

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

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

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

platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it

Wakeup for IRQ1 should be disabled only in cases where i8042 had actually enabled it, otherwise "wakedepth" for this IRQ will try to drop below zero and there will be an unpleasant WARN() logged:

kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug kernel: ------------[ cut here ]------------ kernel: Unbalanced IRQ 1 wake disable kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irqsetirqwake+0x147/0x1a0

The PMC driver uses DEFINESIMPLEDEVPMOPS() to define its devpmops which sets amdpmcsuspendhandler() to the .suspend, .freeze, and .poweroff handlers. i8042pmsuspend(), however, is only set as the .suspend handler.

Fix the issue by call PMC suspend handler only from the same set of devpmops handlers as i8042pmsuspend(), which currently means just the .suspend handler.

To reproduce this issue try hibernating (S4) the machine after a fresh boot without putting it into s2idle first.

[ij: edited the commit message.]

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

rcu/nocb: Fix possible invalid rdp's->nocbcbkthread pointer access

In the preparation stage of CPU online, if the corresponding the rdp's->nocbcbkthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocbcbkthread pointer, but this rdp's->nocbgprdp and rdp's->rdpgp->nocbgpkthread is still valid.

This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthreadunpark() will access invalid rdp's->nocbcbkthread pointer.

This commit therefore use rdp's->nocbgpkthread instead of rdpgp's->nocbgpkthread for safety check.

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

netfilter: nfreject: don't leak dst refcount for loopback packets

recent patches to add a WARN() when replacing skb dst entry found an old bug:

WARNING: include/linux/skbuff.h:1165 skbdstcheckunset include/linux/skbuff.h:1164 [inline] WARNING: include/linux/skbuff.h:1165 skbdstset include/linux/skbuff.h:1210 [inline] WARNING: include/linux/skbuff.h:1165 nfrejectfillskbdst+0x2a4/0x330 net/ipv4/netfilter/nfrejectipv4.c:234 [..] Call Trace: nfsendunreach+0x17b/0x6e0 net/ipv4/netfilter/nfrejectipv4.c:325 nftrejectineteval+0x4bc/0x690 net/netfilter/nftrejectinet.c:27 exprcallopseval net/netfilter/nftablescore.c:237 [inline] ..

This is because blamed commit forgot about loopback packets. Such packets already have a dstentry attached, even at PREROUTING stage.

Instead of checking hook just check if the skb already has a route attached to it.

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

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.

drm/amdgpu: avoid buffer overflow attach in smusyssetpptable()

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:

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.

bpf: Forget ranges when refining tnum after JSET

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

libceph: return the handler error from monhandleauthdone()

Currently any error from cephauthhandlereplydone() is propagated via finishauth() but isn't returned from monhandleauthdone(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setupcrypto() and later lead to a NULL pointer dereference inside of prepareauthsignature().

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

x86/mm/64: define ARCHPAGETABLESYNCMASK and archsynckernelmappings()

Define ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure page tables are properly synchronized when calling pdpopulatekernel().

For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel().

This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbusprobe+0x6d/0xc9 [... snip ...] </TASK>

It also fixes a crash in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds() [1]:

BUG: unable to handle page fault for address: ffffeb3ff1200000 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI Tainted: [W]=WARN RIP: 0010:vmemmapsetpmd+0xff/0x230 <TASK> vmemmappopulatehugepages+0x176/0x180 vmemmappopulate+0x34/0x80 populatesectionmemmap+0x41/0x90 sparseaddsection+0x121/0x3e0 addpages+0xba/0x150 addpages+0x1d/0x70 memremappages+0x3dc/0x810 devmmemremappages+0x1c/0x60 xedevmadd+0x8b/0x100 [xe] xetileinitnoalloc+0x6a/0x70 [xe] xedeviceprobe+0x48c/0x740 [xe] [... snip ...]

fs: relax assertions on failure to encode file handles

eventpoll: Fix semi-unbounded recursion

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

net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY

DSA has 2 kinds of drivers:

1. Those who call dsaswitchsuspend() and dsaswitchresume() from their device PM ops: qca8k-8xxx, bcmsf2, microchip ksz 2. Those who don't: all others. The above methods should be optional.

For type 1, dsaswitchsuspend() calls dsausersuspend() -> phylinkstop(), and dsaswitchresume() calls dsauserresume() -> phylinkstart(). These seem good candidates for setting macmanagedpm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.

Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdiobusphysuspend() and mdiobusphyresume() should run in full), I have noticed that the following warning from mdiobusphyresume() is triggered:

WARNON(phydev->state != PHYHALTED && phydev->state != PHYREADY && phydev->state != PHYUP);

because the PHY state machine is running.

It's running as a result of a previous dsauseropen() -> ... -> phylinkstart() -> phystart() having been initiated by the user.

The previous mdiobusphysuspend() was supposed to have called phystopmachine(), but it didn't. So this is why the PHY is in state PHYNOLINK by the time mdiobusphyresume() runs.

mdiobusphysuspend() did not call phystopmachine() because for phylink, the phydev->adjustlink function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARNON(), it would have likely been invisible.

This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming macmanagedpm is set correctly, a quick search indicates the following other drivers might be affected:

$ grep -Zlr PHYLINKNETDEV drivers/ | xargs -0 grep -L macmanagedpm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5main.c drivers/net/ethernet/microchip/lan966x/lan966xmain.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fsenet/fsenet-main.c drivers/net/ethernet/freescale/dpaa/dpaaeth.c drivers/net/ethernet/freescale/uccgeth.c drivers/net/ethernet/freescale/enetc/enetcpfcommon.c drivers/net/ethernet/marvell/mvpp2/mvpp2main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/presteramain.c drivers/net/ethernet/mediatek/mtkethsoc.c drivers/net/ethernet/altera/alteratsemain.c drivers/net/ethernet/wangxun/txgbe/txgbephy.c drivers/net/ethernet/meta/fbnic/fbnicphylink.c drivers/net/ethernet/tehuti/tn40phy.c drivers/net/ethernet/mscc/ocelotnet.c

Make the existing conditions dependent on the PHY device having a phydev->phylinkchange() implementation equal to the default phylinkchange() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylinkphychange() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phylinkchange() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.

Thus, for the situation where the PM is not managed b ---truncated---

blk-mq: fix NULL dereference on q->elevator in blkmqelvswitchnone

ext4: fix out-of-bound read in ext4xattrinodedecrefall()

bpf: Do not let BPF test infra emit invalid GSO types to stack

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

nfsd: provide locking for v4endgrace

Writing to v4endgrace can race with server shutdown and result in memory being accessed after it was freed - reclaimstrhashtbl in particularly.

We cannot hold nfsdmutex across the nfsd4endgrace() call as that is held while clienttrackingop->init() is called and that can wait for an upcall to nfsdcltrack which can write to v4endgrace, resulting in a deadlock.

nfsd4endgrace() is also called by the landromat work queue and this doesn't require locking as server shutdown will stop the work and wait for it before freeing anything that nfsd4endgrace() might access.

However, we must be sure that writing to v4endgrace doesn't restart the work item after shutdown has already waited for it. For this we add a new flag protected with nn->clientlock. It is set only while it is safe to make client tracking calls, and v4endgrace only schedules work while the flag is set with the spinlock held.

So this patch adds a nfsdnet field "clienttrackingactive" which is set as described. Another field "graceendforced", is set when v4endgrace is written. After this is set, and providing clienttrackingactive is set, the laundromat is scheduled. This "graceendforced" field bypasses other checks for whether the grace period has finished.

This resolves a race which can result in use-after-free.

fs/buffer: fix use-after-free when call bhread() helper

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

net: stmmac: make sure that ptprate is not 0 before configuring EST

If the ptprate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0.

Prevent this division by 0 by adding the corresponding check and error code.

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.

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

net: clear the dst when changing skb protocol

A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6:

BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6rcvcore (net/ipv6/ip6input.c:190:20) ipv6rcv (net/ipv6/ip6input.c:306:8) processbacklog (net/core/dev.c:6186:4) napipoll (net/core/dev.c:6906:9) netrxaction (net/core/dev.c:7028:13) dosoftirq (kernel/softirq.c:462:3) netifrx (net/core/dev.c:5326:3) devloopbackxmit (net/core/dev.c:4015:2) ipmcfinishoutput (net/ipv4/ipoutput.c:363:8) NFHOOK (./include/linux/netfilter.h:314:9) ipmcoutput (net/ipv4/ipoutput.c:400:5) dstoutput (./include/net/dst.h:459:9) iplocalout (net/ipv4/ipoutput.c:130:9) ipsendskb (net/ipv4/ipoutput.c:1496:8) udpsendskb (net/ipv4/udp.c:1040:8) udpsendmsg (net/ipv4/udp.c:1328:10)

The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netifrx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6rcvcore which tries to use skbdst(). But the dst is still an IPv4 one left after IPv4 mcast output.

Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.

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

NFSD: fix race between nfsd registration and exportsproc

As of now nfsd calls createprocexportsentry() at start of initnfsd and cleanup by removeprocentry() at last of exitnfsd.

Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd

for 5.4 kernel ARM64:

CPU 1: el1irq+0xbc/0x180 archcountergetcntvct+0x14/0x18 runningclock+0xc/0x18 preemptcountadd+0x88/0x110 prepnewpage+0xb0/0x220 getpagefromfreelist+0x2d8/0x1778 allocpagesnodemask+0x15c/0xef0 vmallocnoderange+0x28c/0x478 vmallocnodeflagscaller+0x8c/0xb0 kvmallocnode+0x88/0xe0 nfsdinitnet+0x6c/0x108 [nfsd] opsinit+0x44/0x170 registerpernetoperations+0x114/0x270 registerpernetsubsys+0x34/0x50 initnfsd+0xa8/0x718 [nfsd] dooneinitcall+0x54/0x2e0

CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010

PC is at : exportsnetopen+0x50/0x68 [nfsd]

Call trace: exportsnetopen+0x50/0x68 [nfsd] exportsprocopen+0x2c/0x38 [nfsd] procregopen+0xb8/0x198 dodentryopen+0x1c4/0x418 vfsopen+0x38/0x48 pathopenat+0x28c/0xf18 dofilpopen+0x70/0xe8 dosysopen+0x154/0x248

Sometimes it crashes at exportsnetopen() and sometimes cacheseqnextrcu().

and same is happening on latest 6.14 kernel as well:

[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cacheseqnextrcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cacheseqnextrcu+0x78/0xa4 (P) [ 285.470488] seqread+0xe0/0x11c [ 285.470675] procregread+0x9c/0xf0 [ 285.470874] vfsread+0xc4/0x2fc [ 285.471057] ksysread+0x6c/0xf4 [ 285.471231] arm64sysread+0x1c/0x28 [ 285.471428] invokesyscall+0x44/0x100 [ 285.471633] el0svccommon.constprop.0+0x40/0xe0 [ 285.471870] doel0svccompat+0x1c/0x34 [ 285.472073] el0svccompat+0x2c/0x80 [ 285.472265] el0t32synchandler+0x90/0x140 [ 285.472473] el0t32sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]---

It reproduced simply with below script: while [ 1 ] do /exportfs -r done &

while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done &

So exporting interfaces to user space shall be done at last and cleanup at first place.

With change there is no Kernel OOPs.

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

net: mscc: ocelot: Fix crash when adding interface under a lag

Commit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelotsetaggrpgids() function in the ocelot driver has similar logic and is susceptible to the same crash.

This issue specifically affects the ocelotvsc7514.c frontend, which leaves unused ports as NULL pointers. The felixvsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports.

Fix this by checking if the port pointer is valid before accessing it.

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

netfilter: nftsetpipapo: prevent overflow in lookup table allocation

When calculating the lookup table size, ensure the following multiplication does not overflow:

- desc->fieldlen[] maximum value is U8MAX multiplied by NFTPIPAPOGROUPSPERBYTE(f) that can be 2, worst case. - NFTPIPAPOBUCKETS(f->bb) is 2^8, worst case. - sizeof(unsigned long), from sizeof(f->lt), lt in struct nftpipapofield.

Then, use checkmuloverflow() to multiply by bucket size and then use checkaddoverflow() to the alignment for avx2 (if needed). Finally, add ltsizecheckoverflow() helper and use it to consolidate this.

While at it, replace leftover allocation using the GFPKERNEL to GFPKERNELACCOUNT for consistency, in pipaporesize().