drm/dpmst: Ensure mstprimary pointer is valid in drmdpmsthandleupreq()

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

wifi: cfg80211: clear link ID from bitmap during link delete after clean up

Currently, during link deletion, the link ID is first removed from the validlinks bitmap before performing any clean-up operations. However, some functions require the link ID to remain in the validlinks bitmap. One such example is cfg80211cacevent(). The flow is -

nl80211removelink() cfg80211removelink() ieee80211delintflink() ieee80211vifsetlinks() ieee80211vifupdatelinks() ieee80211linkstop() cfg80211cacevent()

cfg80211cacevent() requires link ID to be present but it is cleared already in cfg80211removelink(). Ultimately, WARNON() is hit.

Therefore, clear the link ID from the bitmap only after completing the link clean-up.

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

net: hsr: must allocate more bytes for RedBox support

Blamed commit forgot to change hsrinitskb() to allocate larger skb for RedBox case.

Indeed, sendhsrsupervisionframe() will add two additional components (struct hsrsuptlv and struct hsrsuppayload)

syzbot reported the following crash: skbuff: skboverpanic: text:ffffffff8afd4b0a len:34 put:6 head:ffff88802ad29e00 data:ffff88802ad29f22 tail:0x144 end:0x140 dev:gretap0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 2 UID: 0 PID: 7611 Comm: syz-executor Not tainted 6.12.0-syzkaller #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:skbpanic+0x157/0x1d0 net/core/skbuff.c:206 Code: b6 04 01 84 c0 74 04 3c 03 7e 21 8b 4b 70 41 56 45 89 e8 48 c7 c7 a0 7d 9b 8c 41 57 56 48 89 ee 52 4c 89 e2 e8 9a 76 79 f8 90 <0f> 0b 4c 89 4c 24 10 48 89 54 24 08 48 89 34 24 e8 94 76 fb f8 4c RSP: 0018:ffffc90000858ab8 EFLAGS: 00010282 RAX: 0000000000000087 RBX: ffff8880598c08c0 RCX: ffffffff816d3e69 RDX: 0000000000000000 RSI: ffffffff816de786 RDI: 0000000000000005 RBP: ffffffff8c9b91c0 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000302 R11: ffffffff961cc1d0 R12: ffffffff8afd4b0a R13: 0000000000000006 R14: ffff88804b938130 R15: 0000000000000140 FS: 000055558a3d6500(0000) GS:ffff88806a800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1295974ff8 CR3: 000000002ab6e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> skboverpanic net/core/skbuff.c:211 [inline] skbput+0x174/0x1b0 net/core/skbuff.c:2617 sendhsrsupervisionframe+0x6fa/0x9e0 net/hsr/hsrdevice.c:342 hsrproxyannounce+0x1a3/0x4a0 net/hsr/hsrdevice.c:436 calltimerfn+0x1a0/0x610 kernel/time/timer.c:1794 expiretimers kernel/time/timer.c:1845 [inline] runtimers+0x6e8/0x930 kernel/time/timer.c:2419 runtimerbase kernel/time/timer.c:2430 [inline] runtimerbase kernel/time/timer.c:2423 [inline] runtimerbase+0x111/0x190 kernel/time/timer.c:2439 runtimersoftirq+0x1a/0x40 kernel/time/timer.c:2449 handlesoftirqs+0x213/0x8f0 kernel/softirq.c:554 dosoftirq kernel/softirq.c:588 [inline] invokesoftirq kernel/softirq.c:428 [inline] irqexitrcu kernel/softirq.c:637 [inline] irqexitrcu+0xbb/0x120 kernel/softirq.c:649 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>

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

net: hns3: don't auto enable misc vector

Currently, there is a time window between misc irq enabled and service task inited. If an interrupte is reported at this time, it will cause warning like below:

[ 16.324639] Call trace: [ 16.324641] queuedelayedwork+0xb8/0xe0 [ 16.324643] moddelayedworkon+0x78/0xd0 [ 16.324655] hclgeerrhandtaskschedule+0x58/0x90 [hclge] [ 16.324662] hclgemiscirqhandle+0x168/0x240 [hclge] [ 16.324666] handleirqeventpercpu+0x64/0x1e0 [ 16.324667] handleirqevent+0x80/0x170 [ 16.324670] handlefasteoiedgeirq+0x110/0x2bc [ 16.324671] handledomainirq+0x84/0xfc [ 16.324673] gichandleirq+0x88/0x2c0 [ 16.324674] el1irq+0xb8/0x140 [ 16.324677] archcpuidle+0x18/0x40 [ 16.324679] defaultidlecall+0x5c/0x1bc [ 16.324682] cpuidleidlecall+0x18c/0x1c4 [ 16.324684] doidle+0x174/0x17c [ 16.324685] cpustartupentry+0x30/0x6c [ 16.324687] secondarystartkernel+0x1a4/0x280 [ 16.324688] ---[ end trace 6aa0bff672a964aa ]---

So don't auto enable misc vector when request irq..

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

net: hns3: fix kernel crash when 1588 is sent on HIP08 devices

Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTXHWTSTAMP flag and cause a kernel crash.

[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclgeptpsettxinfo+0x2c/0x140 [hclge] [ 128.286600] lr : hclgeptpsettxinfo+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclgeptpsettxinfo+0x2c/0x140 [hclge] [ 128.399893] hns3nicnetxmit+0x39c/0x4c4 [hns3] [ 128.405468] xmitone.constprop.0+0xc4/0x200 [ 128.410600] devhardstartxmit+0x54/0xf0 [ 128.415556] schdirectxmit+0xe8/0x634 [ 128.420246] devqueuexmit+0x224/0xc70 [ 128.425101] devqueuexmit+0x1c/0x40 [ 128.429608] ovsvportsend+0xac/0x1a0 [openvswitch] [ 128.435409] dooutput+0x60/0x17c [openvswitch] [ 128.440770] doexecuteactions+0x898/0x8c4 [openvswitch] [ 128.446993] ovsexecuteactions+0x64/0xf0 [openvswitch] [ 128.453129] ovsdpprocesspacket+0xa0/0x224 [openvswitch] [ 128.459530] ovsvportreceive+0x7c/0xfc [openvswitch] [ 128.465497] internaldevxmit+0x34/0xb0 [openvswitch] [ 128.471460] xmitone.constprop.0+0xc4/0x200 [ 128.476561] devhardstartxmit+0x54/0xf0 [ 128.481489] devqueuexmit+0x968/0xc70 [ 128.486330] devqueuexmit+0x1c/0x40 [ 128.490856] ipfinishoutput2+0x250/0x570 [ 128.495810] ipfinishoutput+0x170/0x1e0 [ 128.500832] ipfinishoutput+0x3c/0xf0 [ 128.505504] ipoutput+0xbc/0x160 [ 128.509654] ipsendskb+0x58/0xd4 [ 128.513892] udpsendskb+0x12c/0x354 [ 128.518387] udpsendmsg+0x7a8/0x9c0 [ 128.522793] inetsendmsg+0x4c/0x8c [ 128.527116] socksendmsg+0x48/0x80 [ 128.531609] syssendto+0x124/0x164 [ 128.536099] arm64syssendto+0x30/0x5c [ 128.540935] invokesyscall+0x50/0x130 [ 128.545508] el0svccommon.constprop.0+0x10c/0x124 [ 128.551205] doel0svc+0x34/0xdc [ 128.555347] el0svc+0x20/0x30 [ 128.559227] el0synchandler+0xb8/0xc0 [ 128.563883] el0sync+0x160/0x180

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

mm: clear uffd-wp PTE/PMD state on mremap()

When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.

Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.

eth: bnxt: always recalculate features after XDP clearing, fix null-deref

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

net: fec: handle pagepooldevallocpages error

The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!newpage) but it would still proceed to use the NULL pointer and then crash.

This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.

Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.

This commit handles the allocation error by dropping the current packet.

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

iouring/eventfd: ensure ioeventfdsignal() defers another RCU period

ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioevfd should be deferred another RCU grace period.

Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.

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

netfilter: conntrack: clamp maximum hashtable size to INTMAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in kvmallocnodenoprof() when resizing hashtable because GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from initnetns.

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.]

fs: relax assertions on failure to encode file handles

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

topology: Keep the cpumask unchanged when printing cpumap

During fuzz testing, the following warning was discovered:

different return values (15 and 11) from vsnprintf("%pbl ", ...)

test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2

The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:

(1) First, calculate the length of the resulting formatted string.

(2) Allocate a buffer based on the returned length.

(3) Then, perform the actual string formatting.

(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.

If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.

To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.

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

net: stmmac: fix TSO DMA API usage causing oops

Commit 66600fac7a98 ("net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data") moved the assignment of txskbuffdma[]'s members to be later in stmmactsoxmit().

The buf (dma cookie) and len stored in this structure are passed to dmaunmapsingle() by stmmactxclean(). The DMA API requires that the dma cookie passed to dmaunmapsingle() is the same as the value returned from dmamapsingle(). However, by moving the assignment later, this is not the case when priv->dmacap.addr64 > 32 as "des" is offset by protohdrlen.

This causes problems such as:

dwc-eth-dwmac 2490000.ethernet eth0: Tx DMA map failed

and with DMAAPIDEBUG enabled:

DMA-API: dwc-eth-dwmac 2490000.ethernet: device driver tries to +free DMA memory it has not allocated [device address=0x000000ffffcf65c0] [size=66 bytes]

Fix this by maintaining "des" as the original DMA cookie, and use tsodes to pass the offset DMA cookie to stmmactsoallocator().

Full details of the crashes can be found at: https://lore.kernel.org/all/d8112193-0386-4e14-b516-37c2d838171a@nvidia.com/ https://lore.kernel.org/all/klkzp5yn5kq5efgtrow6wbvnc46bcqfxs65nz3qy77ujr5turc@bwwhelz2l4dw/

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

scsi: sg: Fix slab-use-after-free read in sgrelease()

Fix a use-after-free bug in sgrelease(), detected by syzbot with KASAN:

BUG: KASAN: slab-use-after-free in lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5838 mutexunlockslowpath+0xe2/0x750 kernel/locking/mutex.c:912 sgrelease+0x1f4/0x2e0 drivers/scsi/sg.c:407

In sgrelease(), the function krefput(&sfp->fref, sgremovesfp) is called before releasing the openrellock mutex. The krefput() call may decrement the reference count of sfp to zero, triggering its cleanup through sgremovesfp(). This cleanup includes scheduling deferred work via sgremovesfpusercontext(), which ultimately frees sfp.

After krefput(), sgrelease() continues to unlock openrellock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.

Move the krefput(&sfp->fref, sgremovesfp) call after unlocking the openrellock mutex. This ensures:

- No references to sfp or sdp occur after the reference count is decremented.

- Cleanup functions such as sgremovesfp() and sgremovesfpusercontext() can safely execute without impacting the mutex handling in sgrelease().

The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sgrelease().

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

mm: zswap: properly synchronize freeing resources during CPU hotunplug

In zswapcompress() and zswapdecompress(), the per-CPU acompctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.

If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).

The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.

Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acompctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.

The initialization of acompctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.

Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronizesrcu() cannot be used in CPU hotplug notifiers [2].

Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acompctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.

[1]

bpf: check changespktdata property for extension programs

afpacket: fix vlangetprotocoldgram() vs MSGPEEK

afpacket: fix vlangettci() vs MSGPEEK

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

riscv: Fix sleeping in invalid context in die()

die() can be called in exception handler, and therefore cannot sleep. However, die() takes spinlockt which can sleep with PREEMPTRT enabled. That causes the following warning:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 285, name: mutex preemptcount: 110001, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234 Hardware name: riscv-virtio,qemu (DT) Call Trace: dumpbacktrace+0x1c/0x24 showstack+0x2c/0x38 dumpstacklvl+0x5a/0x72 dumpstack+0x14/0x1c mightresched+0x130/0x13a rtspinlock+0x2a/0x5c die+0x24/0x112 dotrapinsnillegal+0xa0/0xea newvmallocrestorecontexta0+0xcc/0xd8 Oops - illegal instruction [#1]

Switch to use rawspinlockt, which does not sleep even with PREEMPTRT enabled.

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

virtio-blk: don't keep queue frozen during system suspend

Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending.

block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bioqueueenter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblkfreeze().

[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/

Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend.

gfs2: Truncate address space when flipping GFS2DIFJDATA flag

drm/v3d: Ensure job pointer is set to NULL after job completion

hrtimers: Handle CPU state correctly on hotplug

fs/proc: fix softlockup in readvmcore (part 2)

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.

btrfs: avoid NULL pointer dereference if no valid extent tree

exfat: fix the infinite loop in exfatreaddir()

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

net/sctp: Prevent autoclose integer overflow in sctpassociationinit()

While by default maxautoclose equals to INTMAX / HZ, one may set net.sctp.maxautoclose to UINTMAX. There is code in sctpassociationinit() that can consequently trigger overflow.

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

mptcp: fix TCP options overflow.

Syzbot reported the following splat:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:compoundhead include/linux/page-flags.h:242 [inline] RIP: 0010:putpage+0x23/0x260 include/linux/mm.h:1552 Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83 RSP: 0000:ffffc90003916c90 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007 R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpageunref include/linux/skbuffref.h:43 [inline] skbfragunref include/linux/skbuffref.h:56 [inline] skbreleasedata+0x483/0x8a0 net/core/skbuff.c:1119 skbreleaseall net/core/skbuff.c:1190 [inline] kfreeskb+0x55/0x70 net/core/skbuff.c:1204 tcpcleanrtxqueue net/ipv4/tcpinput.c:3436 [inline] tcpack+0x2442/0x6bc0 net/ipv4/tcpinput.c:4032 tcprcvstateprocess+0x8eb/0x44e0 net/ipv4/tcpinput.c:6805 tcpv4dorcv+0x77d/0xc70 net/ipv4/tcpipv4.c:1939 tcpv4rcv+0x2dc0/0x37f0 net/ipv4/tcpipv4.c:2351 ipprotocoldeliverrcu+0x22e/0x440 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x341/0x5f0 net/ipv4/ipinput.c:233 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 netifreceiveskbonecore net/core/dev.c:5672 [inline] netifreceiveskb+0x2bf/0x650 net/core/dev.c:5785 processbacklog+0x662/0x15b0 net/core/dev.c:6117 napipoll+0xcb/0x490 net/core/dev.c:6883 napipoll net/core/dev.c:6952 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:7074 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] irqexitrcu+0xf7/0x220 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049 asmsysvecapictimerinterrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0033:0x7f34f4519ad5 Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246 RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5 RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0 RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000 R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4 R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68 </TASK>

Eric noted a probable shinfo->nrfrags corruption, which indeed occurs.

The root cause is a buggy MPTCP option len computation in some circumstances: the ADDADDR option should be mutually exclusive with DSS since the blamed commit.

Still, mptcpestablishedoptionsaddaddr() tries to set the relevant info in mptcpoutoptions, if ---truncated---