drm/amdgpu/sdma4: replace BUGON with WARNON in fence emission

bpf: testrun: Fix the null pointer dereference issue in bpflwtxmitpushencap

bpf: reject short IPv4/IPv6 inputs in bpfprogtestrunskb

btrfs: fix missing lastunlinktrans update when removing a directory

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

scsi: target: core: Fix integer overflow in UNMAP bounds check

sbcexecuteunmap() checks LBA + range does not exceed the device capacity, but does not guard against LBA + range wrapping around on 64-bit overflow.

Add an overflow check matching the pattern already used for WRITESAME in the same file.

drm/amdgpu: Limit BO list entry count to prevent resource exhaustion

clockevents: Add missing resets of the nexteventforced flag

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

lib/crypto: mpi: Fix integer underflow in mpireadrawfromsgl()

Yiming reports an integer underflow in mpireadrawfromsgl() when subtracting "lzeros" from the unsigned "nbytes".

For this to happen, the scatterlist "sgl" needs to occupy more bytes than the "nbytes" parameter and the first "nbytes + 1" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than "nbytes", subtract the number of zeroes from "nbytes" and cause the underflow.

When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally introduced the bug, it couldn't be triggered because all callers of mpireadrawfromsgl() passed a scatterlist whose length was equal to "nbytes".

However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists"), the underflow can now actually be triggered. When invoking a KEYCTLPKEYENCRYPT system call with a larger "outlen" than "inlen" and filling the "in" buffer with zeroes, cryptoakciphersyncprep() will create an all-zero scatterlist used for both the "src" and "dst" member of struct akcipherrequest and thereby fulfil the conditions to trigger the bug:

syskeyctl() keyctlpkeyeds() asymmetrickeyedsop() softwarekeyedsop() cryptoakciphersyncencrypt() cryptoakciphersyncprep() cryptoakcipherencrypt() rsaenc() mpireadrawfromsgl()

To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect.

Fix it.

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

net: qrtr: ns: Limit the maximum server registration per node

Current code does no bound checking on the number of servers added per node. A malicious client can flood NEWSERVER messages and exhaust memory.

Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEWSERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtrnsworker().

Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.

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

net/sched: schred: Replace direct dequeue call with peek and qdiscdequeuepeeked

When red qdisc has children (eg qfq qdisc) whose peek() callback is qdiscpeekdequeued(), we could get a kernel panic. When the parent of such qdiscs (eg illustrated in patch #3 as tbf) wants to retrieve an skb from its child (red in this case), it will do the following: 1a. do a peek() - and when sensing there's an skb the child can offer, then - the child in this case(red) calls its child's (qfq) peek. qfq does the right thing and will return the gsoskb queue packet. Note: if there wasnt a gsoskb entry then qfq will store it there. 1b. invoke a dequeue() on the child (red). And herein lies the problem. - red will call the child's dequeue() which will essentially just try to grab something of qfq's queue.

[ 78.667668][ T363] KASAN: null-ptr-deref in range [0x0000000000000048-0x000000000000004f] [ 78.667927][ T363] CPU: 1 UID: 0 PID: 363 Comm: ping Not tainted 7.1.0-rc1-00033-g46f74a3f7d57-dirty #790 PREEMPT(full) [ 78.668263][ T363] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 78.668486][ T363] RIP: 0010:qfqdequeue+0x446/0xc90 [schqfq] [ 78.668718][ T363] Code: 54 c0 e8 dd 90 00 f1 48 c7 c7 e0 03 54 c0 48 89 de e8 ce 90 00 f1 48 8d 7b 48 b8 ff ff 37 00 48 89 fa 48 c1 e0 2a 48 c1 ea 03 <80> 3c 02 00 74 05 e8 ef a1 e1 f1 48 8b 7b 48 48 8d 54 24 58 48 8d [ 78.669312][ T363] RSP: 0018:ffff88810de573e0 EFLAGS: 00010216 [ 78.669533][ T363] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 78.669790][ T363] RDX: 0000000000000009 RSI: 0000000000000004 RDI: 0000000000000048 [ 78.670044][ T363] RBP: ffff888110dc4000 R08: ffffffffb1b0885a R09: fffffbfff6ba9078 [ 78.670297][ T363] R10: 0000000000000003 R11: ffff888110e31c80 R12: 0000001880000000 [ 78.670560][ T363] R13: ffff888110dc4150 R14: ffff888110dc42b8 R15: 0000000000000200 [ 78.670814][ T363] FS: 00007f66a8f09c40(0000) GS:ffff888163428000(0000) knlGS:0000000000000000 [ 78.671110][ T363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 78.671324][ T363] CR2: 000055db4c6a30a8 CR3: 000000010da67000 CR4: 0000000000750ef0 [ 78.671585][ T363] PKRU: 55555554 [ 78.671713][ T363] Call Trace: [ 78.671843][ T363] <TASK> [ 78.671936][ T363] ? pfxqfqdequeue+0x10/0x10 [schqfq] [ 78.672148][ T363] ? pfxprintk+0x10/0x10 [ 78.672322][ T363] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 78.672496][ T363] ? lockdephardirqsonprepare+0xa8/0x1a0 [ 78.672706][ T363] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 78.672875][ T363] ? tracehardirqson+0x19/0x1a0 [ 78.673047][ T363] reddequeue+0x65/0x270 [schred] [ 78.673217][ T363] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 78.673385][ T363] tbfdequeue.cold+0xb0/0x70c [schtbf] [ 78.673566][ T363] qdiscrun+0x169/0x1900

The right thing to do in #1b is to grab the skb off gsoskb queue. This patchset fixes that issue by changing #1b to use qdiscdequeuepeeked() method instead.

Bluetooth: L2CAP: Fix null-ptr-deref in l2capsockstatechangecb()

Bluetooth: L2CAP: Fix null-ptr-deref in l2capsockgetsndtimeocb()

Bluetooth: L2CAP: Fix null-ptr-deref in l2capsocknewconnectioncb()

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

netfilter: nfnetlinkosf: fix divide-by-zero in OSFWSSMODULO

nfosfmatchone() computes ctx->window % f->wss.val in the OSFWSSMODULO branch with no guard for f->wss.val == 0. A CAPNETADMIN user can add such a fingerprint via nfnetlink; a subsequent matching TCP SYN divides by zero and panics the kernel.

Reject the bogus fingerprint in nfnlosfaddcallback() above the per-option for-loop. f->wss is per-fingerprint, not per-option, so the check must run regardless of f->optnum (including 0). Also reject wss.wc >= OSFWSSMAX; nfosfmatchone() already treats that as "should not happen".

Crash: Oops: divide error: 0000 [#1] SMP KASAN NOPTI RIP: 0010:nfosfmatchone (net/netfilter/nfnetlinkosf.c:98) Call Trace: <IRQ> nfosfmatch (net/netfilter/nfnetlinkosf.c:220) xtosfmatchpacket (net/netfilter/xtosf.c:32) iptdotable (net/ipv4/netfilter/iptables.c:348) nfhookslow (net/netfilter/core.c:622) iplocaldeliver (net/ipv4/ipinput.c:265) iprcv (include/linux/skbuff.h:1162) netifreceiveskbonecore (net/core/dev.c:6181) processbacklog (net/core/dev.c:6642) napipoll (net/core/dev.c:7710) netrxaction (net/core/dev.c:7945) handlesoftirqs (kernel/softirq.c:622)

bpf: fix end-of-list detection in cgroupstoragegetnextkey()

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

net/sched: taprio: fix NULL pointer dereference in class dump

When a TAPRIO child qdisc is deleted via RTMDELQDISC, tapriograft() is called with new == NULL and stores NULL into q->qdiscs[cl - 1]. Subsequent RTMGETTCLASS dump operations walk all classes via tapriowalk() and call tapriodumpclass(), which calls taprioleaf() returning the NULL pointer, then dereferences it to read child->handle, causing a kernel NULL pointer dereference.

The bug is reachable with namespace-scoped CAPNETADMIN on any kernel with CONFIGNETSCHTAPRIO enabled. On systems with unprivileged user namespaces enabled, an unprivileged local user can trigger a kernel panic by creating a taprio qdisc inside a new network namespace, grafting an explicit child qdisc, deleting it, and requesting a class dump. The RTMGETTCLASS dump itself requires no capability.

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000007: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] RIP: 0010:tapriodumpclass (net/sched/schtaprio.c:2478) Call Trace: <TASK> tcfilltclass (net/sched/schapi.c:1966) qdiscclassdump (net/sched/schapi.c:2326) tapriowalk (net/sched/schtaprio.c:2514) tcdumptclassqdisc (net/sched/schapi.c:2352) tcdumptclassroot (net/sched/schapi.c:2370) tcdumptclass (net/sched/schapi.c:2431) rtnldumpit (net/core/rtnetlink.c:6864) netlinkdump (net/netlink/afnetlink.c:2325) rtnetlinkrcvmsg (net/core/rtnetlink.c:6959) netlinkrcvskb (net/netlink/afnetlink.c:2550) </TASK>

Fix this by substituting &noopqdisc when new is NULL in tapriograft(), a common pattern used by other qdiscs (e.g., multiqgraft()) to ensure the q->qdiscs[] slots are never NULL. This makes control-plane dump paths safe without requiring individual NULL checks.

Since the data-plane paths (taprioenqueue and tapriodequeuefromtxq) previously had explicit NULL guards that would drop/skip the packet cleanly, update those checks to test for &noopqdisc instead. Without this, packets would reach taprioenqueueone() which increments the root qdisc's qlen and backlog before calling the child's enqueue; noopqdisc drops the packet but those counters are never rolled back, permanently inflating the root qdisc's statistics.

After this change old can be a valid qdisc, NULL, or &noopqdisc. Only call qdiscput(old) in the first case to avoid decreasing noopqdisc's refcount, which was never increased.

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

netfilter: arptables: fix IEEE1394 ARP payload parsing

Weiming Shi says:

"arppacketmatch() unconditionally parses the ARP payload assuming two hardware addresses are present (source and target). However, IPv4-over-IEEE1394 ARP (RFC 2734) omits the target hardware address field, and arphdrlen() already accounts for this by returning a shorter length for ARPHRDIEEE1394 devices.

As a result, on IEEE1394 interfaces arppacketmatch() advances past a nonexistent target hardware address and reads the wrong bytes for both the target device address comparison and the target IP address. This causes arptables rules to match against garbage data, leading to incorrect filtering decisions: packets that should be accepted may be dropped and vice versa.

The ARP stack in net/ipv4/arp.c (arpcreate and arpprocess) already handles this correctly by skipping the target hardware address for ARPHRDIEEE1394. Apply the same pattern to arppacketmatch()."

Mangle the original patch to always return 0 (no match) in case user matches on the target hardware address which is never present in IEEE1394.

Note that this returns 0 (no match) for either normal and inverse match because matching in the target hardware address in ARPHRDIEEE1394 has never been supported by arptables. This is intentional, matching on the target hardware address should never evaluate true for ARPHRDIEEE1394.

Moreover, adjust arptmangle to drop the packet too as AI suggests:

In arptmangle, the logic assumes a standard ARP layout. Because IEEE1394 (FireWire) omits the target hardware address, the linear pointer arithmetic miscalculates the offset for the target IP address. This causes mangling operations to write to the wrong location, leading to packet corruption. To ensure safety, this patch drops packets (NFDROP) when mangling is requested for these fields on IEEE1394 devices, as the current implementation cannot correctly map the FireWire ARP payload.

This omits both mangling target hardware and IP address. Even if IP address mangling should be possible in IEEE1394, this would require to adjust arptmangle offset calculation, which has never been supported.

Based on patch from Weiming Shi <bestswngs@gmail.com>.

bareudp: fix NULL pointer dereference in bareudpfillmetadatadst()

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

slip: reject VJ receive packets on instances with no rstate array

slhcinit() accepts rslots == 0 as a valid configuration, with the documented meaning of 'no receive compression'. In that case the allocation loop in slhcinit() is skipped, so comp->rstate stays NULL and comp->rslotlimit stays 0 (from the kzalloc of struct slcompress).

The receive helpers do not defend against that configuration. slhcuncompress() dereferences comp->rstate[x] when the VJ header carries an explicit connection ID, and slhcremember() later assigns cs = &comp->rstate[...] after only comparing the packet's slot number to comp->rslotlimit. Because rslotlimit is 0, slot 0 passes the range check, and the code dereferences a NULL rstate.

The configuration is reachable in-tree through PPP. PPPIOCSMAXCID stores its argument in a signed int, and (val >> 16) uses arithmetic shift. Passing 0xffff0000 therefore sign-extends to -1, so val2 + 1 is 0 and pppgeneric.c ends up calling slhcinit(0, 1). Because /dev/ppp open is gated by nscapable(CAPNETADMIN), the whole path is reachable from an unprivileged user namespace. Once the malformed VJ state is installed, any inbound VJ-compressed or VJ-uncompressed frame that selects slot 0 crashes the kernel in softirq context:

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:slhcuncompress (drivers/net/slip/slhc.c:519) Call Trace: <TASK> pppreceivenonmpframe (drivers/net/ppp/pppgeneric.c:2466) pppinput (drivers/net/ppp/pppgeneric.c:2359) pppasyncprocess (drivers/net/ppp/pppasync.c:492) taskletactioncommon (kernel/softirq.c:926) handlesoftirqs (kernel/softirq.c:623) runksoftirqd (kernel/softirq.c:1055) smpbootthreadfn (kernel/smpboot.c:160) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:164) </TASK>

Reject the receive side on such instances instead of touching rstate. slhcuncompress() falls through to its existing 'bad' label, which bumps slsierror and enters the toss state. slhcremember() mirrors that with an explicit slsierror increment followed by slhctoss(); the slsirunt counter is not used here because a missing rstate is an internal configuration state, not a runt packet.

The transmit path is unaffected: the only in-tree caller that picks rslots from userspace (pppgeneric.c) still supplies tslots >= 1, and slip.c always calls slhcinit(16, 16), so comp->tstate remains valid and slhccompress() continues to work.

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

ext4: don't zero the entire extent if EXT4EXTDATAPARTIALVALID1

When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle.

0 A B N [UUUUUUUUUUUU] U: unwritten extent [--DDDDDDDD--] D: valid data |<- ->| ----> this range needs to be initialized

ext4splitextent() first try to split this extent at B with EXT4EXTDATAENTIREVALID1 and EXT4EXTMAYZEROOUT flag set, but ext4splitextentat() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written.

0 A B N [WWWWWWWWWWWW] W: written extent [SSDDDDDDDDZZ] Z: zeroed, S: stale data

ext4splitextent() then try to split this extent at A with EXT4EXTDATAVALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A.

0 A B N [WW|WWWWWWWWWW] [SS|DDDDDDDDZZ]

Fix this by pass EXT4EXTDATAPARTIALVALID1 to ext4splitextentat() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4splitextent() will pass the EXT4EXTDATAVALID2 flag when it calls ext4splitextentat() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten.

ALSA: caiaq: fix usbdev refcount leak on probe failure

crypto: ccree - fix a memory leak in ccmacdigest()

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

thermal: core: Fix thermal zone governor cleanup issues

If thermalzonedeviceregisterwithtrips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak.

In turn, thermalzonedeviceunregister() calls thermalsetgovernor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case.

Address these issues by adding two thermalsetgovernor() calls, one to thermalrelease() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.

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

remoteproc: xlnx: Only access buffer information if IPI is buffered

In the receive callback check if message is NULL to prevent possibility of crash by NULL pointer dereferencing.

ALSA: ctxfi: Add fallback to default RSR for S/PDIF

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

KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2

After VMRUN in guest mode, nestedsynccontrolfromvmcb02() syncs fields written by the CPU from vmcb02 to the cached vmcb12. This is because the cached vmcb12 is used as the authoritative copy of some of the controls, and is the payload when saving/restoring nested state.

intstate is also written by the CPU, specifically bit 0 (i.e. SVMINTERRUPTSHADOWMASK) for nested VMs, but it is not sync'd to cached vmcb12. This does not cause a problem if KVMSETNESTEDSTATE preceeds KVMSETVCPUEVENTS in the restore path, as an interrupt shadow would be correctly restored to vmcb02 (KVMSETVCPUEVENTS overwrites what KVMSETNESTEDSTATE restored in intstate).

However, if KVMSETVCPUEVENTS preceeds KVMSETNESTEDSTATE, an interrupt shadow would be restored into vmcb01 instead of vmcb02. This would mostly be benign for L1 (delays an interrupt), but not for L2. For L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before a HLT that should have been in an interrupt shadow).

Sync intstate to the cached vmcb12 in nestedsynccontrolfromvmcb02() to avoid this problem. With that, KVMSETNESTEDSTATE restores the correct interrupt shadow state, and if KVMSETVCPUEVENTS follows it would overwrite it with the same value.

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

net: qrtr: ns: Limit the maximum number of lookups

Current code does no bound checking on the number of lookups a client can perform. Though the code restricts the lookups to local clients, there is still a possibility of a malicious local client sending a flood of NEWLOOKUP messages over the same socket.

Fix this issue by limiting the maximum number of lookups to 64 globally. Since the nameserver allows only atmost one local observer, this global lookup count will ensure that the lookups stay within the limit.

Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.

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

net: qrtr: ns: Limit the total number of nodes

Currently, the nameserver doesn't limit the number of nodes it handles. This can be an attack vector if a malicious client starts registering random nodes, leading to memory exhaustion.

Hence, limit the maximum number of nodes to 64. Note that, limit of 64 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.

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

scsi: sd: fix missing putdisk() when deviceadd(&diskdev) fails

If deviceadd(&sdkp->diskdev) fails, putdevice() runs scsidiskrelease(), which frees the scsidisk but leaves the gendisk referenced. The deviceadddisk() error path in sdprobe() calls putdisk(gd); call putdisk(gd) here to mirror that cleanup.

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

rxrpc: Fix conn-level packet handling to unshare RESPONSE packets

The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the skbuff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted).

Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned.