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

ipvs: do not propagate one-packet flag to synced conns

Synced connections can be created before their destination exists. When the destination is later added, ipvsbinddest() copies connection flags from the destination into cp->flags.

IPVSCONNFONEPACKET connections are not synced. If a synced connection inherits IPVSCONNFONEPACKET while it is already hashed, expiry can treat it as a one-packet connection and skip unlinking the existing conntab node, leaving stale hash nodes pointing at a freed struct ipvsconn.

Drop IPVSCONNFONEPACKET from destination flags when binding synced connections.

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

s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs

There is a wrong upper limit check for the domain value when an EP11 CPRB is processed for sending to a crypto card. This check is only active on custom device nodes but may lead to access heap memory behind perms->adm when an administrative CPRB is sent. Add correct limit (APDOMAINS = 256) checking to fix this.

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

net: ethernet: mtkethsoc: pass eth to mtkhandleirqrx in pollcontroller

mtkhandleirqrx expects a struct mtketh (matching the requestirq cookie), but mtkpollcontroller incorrectly passed the netdevice . Calling ndopollcontroller with CONFIGNETPOLLCONTROLLER enabled would then crash.

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

idpf: bound interrupt-vector register fill to the allocated array

idpfgetregintrvecs() fills the caller-allocated regvals[] array from the VIRTCHNL2OPALLOCVECTORS reply in adapter->reqvecchunks, bounding its inner loop only by the per-chunk numvectors. The array is sized separately: idpfintrreginit() allocates kzallocobjs(struct idpfvecregs, totalvecs) from caps.numallocatedvectors and only checks the returned count after the fill. The sum of per-chunk numvectors is never reconciled against totalvecs, so a reply with a small numallocatedvectors but chunks summing higher writes past the end of regvals[].

Impact: a control plane (a PF or hypervisor device model) that returns a VIRTCHNL2OPALLOCVECTORS reply whose per-chunk numvectors sum exceeds numallocatedvectors writes struct idpfvecregs entries past the end of the regvals kmalloc allocation (KASAN slab-out-of-bounds write).

Bound the fill loop to the array capacity passed in by the callers, mirroring the sibling idpfvportgetqreg(). The existing numregs < numvecs check then rejects an undersized reply without the out-of-bounds write happening first.

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

KVM: s390: pci: Fix NULL dereference on AIBV allocation failure

The airqivcreate() can return NULL on failure, but the return value was never checked. If it fails, zdev->aibv will be NULL and fail when dereferenced in kvmzpcisetairq(). Add a NULL check and free the previously allocated AISB bit and zdev->aisb on failure.

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

vxlan: re-fetch eth header after routeshortcircuit()

Before routeshortcircuit(), the eth header pointer is cached from ethhdr(skb).

Inside routeshortcircuit(), pskbmaypull() can be called, which may reallocate skb->head.

In this case, returning to vxlanxmit() leaves the cached eth pointer pointing to freed memory, leading to a use-after-free when dereferencing eth->hdest.

Fix this by updating eth = ethhdr(skb) after calling routeshortcircuit().

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

ntfs: bound the look-ahead attribute-list entry in ntfsexternalattrfind()

When resolving an attribute lookup with a non-zero @lowestvcn, ntfsexternalattrfind() peeks at the next $ATTRIBUTELIST entry to decide whether to keep searching, but bounds that not-yet-validated entry only with "(u8 )nextalentry + 6 < alend" (which proves just bytes 0..6 are in range) and "(u8 )nextalentry + length <= alend" with an attacker-controlled, non-8-aligned length. It then reads nextalentry->lowestvcn (an le64 at offset 8) and the name at nextalentry->nameoffset, both of which can lie past alend -- the exact end of the kvmalloc'd attribute-list buffer (allocated at the on-disk attrlistsize, no rounding). A crafted on-disk $ATTRIBUTELIST whose last entry sits a few bytes before alend therefore yields a slab out-of-bounds read when the inode is read.

Validate the look-ahead entry with ntfsattrlistentryisvalid() (added in patch 1/3) before dereferencing lowestvcn and the name, so the same fixed-header, length and name bounds the main attribute-list walk uses now guard this read too.

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

perf sched: Fix registerpid() overflow, strcpy, and BUGON

registerpid() has several issues when processing untrusted perf.data:

1. Integer overflow: (pid + 1) sizeof(struct taskdesc ) can wrap to a small value on 32-bit systems when pid is large (e.g. 0x40000000), causing realloc to return a tiny buffer followed by out-of-bounds writes in the initialization loop.

2. Heap buffer overflow: strcpy(task->comm, comm) copies the untrusted comm string into a fixed 20-byte COMMLEN buffer with no length check.

3. BUGON on allocation failure: perf.data is untrusted input, so allocation failures should be handled gracefully rather than killing the process.

4. Realloc of sched->tasks assigned directly back, leaking the old pointer on failure; nrtasks incremented before the realloc, leaving corrupted state on failure.

Cap pid at PIDMAXLIMIT (4194304, matching the kernel's maximum on 64-bit), replace strcpy with strlcpy, guard against NULL comm, replace BUGON with NULL returns using safe realloc patterns, and add NULL checks in callers that dereference the result.

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

netfilter: nfconntrackexpect: use conntrack GC to reap expectations

This patch replaces the timer API by GC worker approach for expectations, as it already happened in many other subsystems.

Use the existing conntrack GC worker to iterate over the local list of expectations in the master conntrack to reap expired expectations. Check IPSHELPERBIT to run GC for expectations, set it on for nftct expectation which nevers sets it. Hold the expectation spinlock while iterating over the master conntrack expectation list to synchronize with nfctremoveexpectations(). This also performs runtime packet path garbage collection through the expectation insertion and lookup functions while walking over one of the chains of the global expectation hashtables. Unconfirmed conntrack entries are skipped since ct->ext can be reallocated and dying are skipped since those will be gone soon. Set on IPSHELPERBIT if the helper ct extension is added, then the new GC worker does not need to bump the ct refcount to check if the ct->ext helper is available.

This removes the extra bump on the refcount for expectation timers, this allows to remove several nfctexpectput() calls after the unlink, after this update only refcount remains at 1 while on the expectation hashes.

This patch implicitly addresses a race with the existing timer API allowing an expectation to access a stale exp->master pointer which has been already released when expectation removal loses races with an expiring timer, ie. timerdel() reporting false.

Add a new NFCTEXPECTDEAD flag to reap this expectation via GC. This is needed by nfconntrackunexpectrelated() which is called in error paths to invalidate newly created expectations that has been added into the hashes. These expectactions cannot be inmediately released as GC or nfctremoveexpectations() could race to make it. On expectation insert, the runtime GC reaps stale expectations before checking the expectation limit set by policy.

Set current timestamp in nfctexpectalloc(), then add the expectation policy timeout (or custom timeout specified added on top of this) to specify the expectation lifetime.

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

net/sched: schfqcodel: Do not call qdisctreereducebacklog during peek before restoring qlen

Whenever fqcodel drops packets during peek, it calls qdisctreereducebacklog. An issue arises because it calls qdisctreereducebacklog before it reincrements the qlen. If qlen drops to zero, but peek returns an skb, the parent's qlennotify callback will be executed even though fqcodel still has 1 packet on the queue and, thus, will mistakenly deactivate the parent's class causing issues like a recent report [1] and a wild memory access in qfq:

[ 29.371146][ T360] Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI [ 29.371666][ T360] KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] [ 29.371987][ T360] CPU: 6 UID: 0 PID: 360 Comm: tc Not tainted 7.1.0-rc5-00285-gc530e5b2dbc6-dirty #82 PREEMPT(full) [ 29.372384][ T360] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 29.372620][ T360] RIP: 0010:qfqdeactivateagg (include/linux/list.h:1029 (discriminator 2) include/linux/list.h:1043 (discriminator 2) net/sched/schqfq.c:1369 (discriminator 2) net/sched/schqfq.c:1395 (discriminator 2)) schqfq [ 29.373544][ T360] RSP: 0018:ffff888102417370 EFLAGS: 00010216 [ 29.373800][ T360] RAX: 0000000000000000 RBX: ffff88811224d568 RCX: dffffc0000000000 [ 29.374079][ T360] RDX: 1ffff11021fe1543 RSI: ffff88810ff0aa00 RDI: dffffc0000000000 [ 29.374368][ T360] RBP: ffff88811224c280 R08: dead000000000122 R09: 1bd5a00000000024 [ 29.374649][ T360] R10: fffffbfff7940329 R11: fffffbfff7940329 R12: 0000000000000000 [ 29.374926][ T360] R13: dead000000000100 R14: ffff88811224d580 R15: ffff88811224d578 [ 29.375207][ T360] FS: 00007f5b794e5780(0000) GS:ffff88815d1e9000(0000) knlGS:0000000000000000 [ 29.375545][ T360] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 29.375823][ T360] CR2: 000055ffb091f000 CR3: 000000010a305000 CR4: 0000000000750ef0 [ 29.376103][ T360] PKRU: 55555554 [ 29.376258][ T360] Call Trace: [ 29.376401][ T360] <TASK> ... [ 29.376885][ T360] qfqresetqdisc (net/sched/schqfq.c:357 net/sched/schqfq.c:1487) schqfq [ 29.377074][ T360] qdiscreset (net/sched/schgeneric.c:1057) [ 29.377414][ T360] qdiscdestroy (net/sched/schgeneric.c:1096) [ 29.377600][ T360] qdiscgraft (net/sched/schapi.c:1062 net/sched/schapi.c:1053 net/sched/schapi.c:1159) [ 29.378593][ T360] tcgetqdisc (net/sched/schapi.c:1528 net/sched/schapi.c:1556)

Fix this by only calling qdisctreereducebacklog in peek after the qlen is restored.

[1] http://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/

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

net: airoha: fix foechecktime allocation size

foechecktime is declared as u16 pointer but was allocated with only ppenumentries bytes instead of ppenumentries sizeof(u16).

When airohappefoeverifyentry() is called with hash >= ppenumentries/2, it writes beyond the allocated buffer, causing heap buffer overflow and potential kernel crash.

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

net: lwtunnel: Drop skb metadata before LWT encapsulation

skb metadata is meant for passing information between XDP and TC. It lives in the skb headroom, immediately before skb->data. LWT programs cannot access the skbuff->datameta pseudo-pointer to metadata.

However, LWT encapsulation prepends outer headers, moving skb->data back over the headroom where the metadata sits. On an RX-originated (forwarded) packet that still carries XDP metadata this goes wrong in two different ways, depending on the encap type:

1. Non-BPF LWT encaps (mpls, seg6, ioam6 ...) call skbpush()/skbpull() and silently overwrite the metadata that sits in the headroom.

2) BPF LWT xmit calls bpfskbchangehead(), which uses skbdatamove(). That helper expects metadata immediately before skb->data. But since the IP output path runs LWT xmit before neighbour output has built the outgoing L2 header, for forwarded packets skb->data points at the L3 header while skbmacheader() still points at the old L2 header. skbdatamove() sees metadata ending at skbmacheader(), not before skb->data, warns and clears metadata:

WARNING: CPU: 21 PID: 454557 at include/linux/skbuff.h:4609 skbdatamove+0x47/0x90 CPU: 21 UID: 0 PID: 454557 Comm: napi/iconduit-g Tainted: G O 6.18.21 #1 RIP: 0010:skbdatamove+0x47/0x90 Call Trace: <IRQ> bpfskbchangehead+0xe6/0x1a0 bpfprog...+0x213/0x2e3 runlwtbpf.isra.0+0x1d3/0x360 bpfxmit+0x46/0xe0 lwtunnelxmit+0xa1/0xf0 ipfinishoutput2+0x1e7/0x5e0 ipoutput+0x63/0x100 netifreceiveskbonecore+0x85/0xa0 processbacklog+0x9c/0x150 napipoll+0x2b/0x190 netrxaction+0x40b/0x7f0 handlesoftirqs+0xd2/0x270 dosoftirq+0x3f/0x60 </IRQ>

That is what happens, as for how to fix it - a received packet that carries metadata can reach an encap through any of the three LWT redirect modes:

LWTUNNELSTATEINPUTREDIRECT ip6rcvfinish dstinput lwtunnelinput

LWTUNNELSTATEOUTPUTREDIRECT ip6rcvfinish dstinput ip6forward ip6forwardfinish dstoutput lwtunneloutput

LWTUNNELSTATEXMITREDIRECT ip6rcvfinish dstinput ip6forward ip6forwardfinish dstoutput ip6output ip6finishoutput ip6finishoutput2 lwtunnelxmit

Every encap funnels through the three LWT dispatch helpers, so drop the metadata there, right before handing the skb to the encap op. This single chokepoint covers all encap types and all three redirect modes:

- lwtunnelinput(): seg6, rpl, ila, seg6local - lwtunneloutput(): ioam6 - lwtunnelxmit(): mpls, LWT BPF xmit

Alternatively, we could clear the metadata right after TC ingress hook. That would require a compromise, however. Metadata would become inaccessible from TC egress (in setups where it actually reaches the hook it tact, that is without any L2 tunnels on path).

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

qede: fix out-of-bounds check for cqe->lenlist[]

Move index check before element access.

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

netfilter: nfconntrackirc: fix parsedcc() off-by-one OOB read

parsedcc() treats dataend as an inclusive end pointer, but its only caller passes datalimit = ibptr + datalen, which points one past the last valid byte.

The newline search loop iterates while tmp <= dataend, so when no newline is present, tmp is read at tmp == dataend, one byte beyond the region filled by skbheaderpointer().

ircbuffer is kmalloc'd as MAXSEARCHSIZE + 1 bytes and datalen is capped at MAXSEARCHSIZE, so the stray read does not fault. The byte is uninitialized or stale; if it contains an ASCII digit, simplestrtoul will consume it and produce a wrong DCC IP or port in the conntrack expectation. The extra allocation byte is also a fragile guard: if the cap or allocation size changes, this becomes a real out-of-bounds read.

Change the loop and its post-loop check to use strict less-than, consistent with the caller's exclusive-end convention. Update the function comment accordingly.

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

batman-adv: dat: acquire ARP hw source only after skb realloc

The pskbmaypull() called by batadvgetvid() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.

IBM Concert

block: stop the timeout timer when releasing a never added disk

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

mptcp: avoid combining some incoming suboptions

Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes.

The new restrictions are the same as the ones applied on the output side, with mptcpwriteoptions. The same rules can be reused with a small fix: an MPFASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules:

Which options can be used together?

X: mutually exclusive O: often used together C: can be used together in some cases P: could be used together but we prefer not to (optimisations)

| Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC | |------|------|------|------|------|------|------|------|------| | MPC |------|------|------|------|------|------|------|------| | MPJ | X |------|------|------|------|------|------|------| | DSS | X | X |------|------|------|------|------|------| | ADD | X | X | P |------|------|------|------|------| | RM | C | C | C | P |------|------|------|------| | PRIO | X | C | C | C | C |------|------|------| | FAIL | X | X | C | X | X | X |------|------| | FC | X | X | P | X | X | X | X |------| | RST | X | X | X | X | X | X | O | O | |------|------|------|------|------|------|------|------|------|

The only difference is with the 'P': another stack could send and ADDADDR with other suboptions (DSS, RMADDR), and this should be allowed.

A few points of attention:

- In theory, an MPCAPABLE could be used with a RMADDR, but there is no reason to add it with a SYN. Note that even with a 4th ACK, it doesn't seem to be useful, except when IDs are known in advance via another channel. Better not to break that.

- Now, combining both an MPCAPABLE and an MPJOIN will no longer result to a reject of the two options, but only the second suboption is ignored. That seems OK to do that for this unexpected error. At least now all inconsistent combinations are handled the same way. This could change later in next. This also means the explicit checks for having both MPC + MPJ in subflow.c will now be unreachable. That's fine, they will be removed in a follow-up patch.

- In case of conflicting combinations, the extra suboption(s) is/are ignored: having such combinations either means the remote peer is buggy, or is evil. The simplest action is then taken in this case: stop processing the current suboption.

- In mpopt->suboptions, there is also a bit reserved to the checksum, which can be used in an MPCAPABLE and a DSS. Each time a DSS option can be used in parallel with another option, the checksum can be set, so the verification is combined into a new OPTIONSMPTCPDSS macro.

- An MPCAPABLE ACK can carry a Data-Level Length, and an optional Checksum: they are the same as the ones found in a DSS, because a DSS cannot be used in parallel to an MPCAPABLE. Similarly, even if there is room, a DSS cannot be used with an MPJOIN.

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

libceph: Avoid using invalid osd indices from primarytemp

A corrupted osdmap received from a Ceph monitor or OSD may contain osd indices in its pgtemp, primarytemp, pgupmap, and pgupmapitems parts that don't exist, i.e., that are greater than maxosd or smaller than CEPHHOMELESSOSD (-1). These indices are used to create the up and acting set in cephpgtoupactingosds(), called from calctarget(). While most of these osd indices are checked, the one from primarytemp is not. Subsequently, this may lead to calctarget() returning this (potentially invalid) index as target osd for a (linger) request. Because the osdstate, osdweight, and osdaddr arrays only contain maxosd entries (with indices 0 to maxosd -1), this leads to out-of-bounds accesses when trying to read values from these arrays.

This patch fixes the issue by adding a check to gettemposds(), so that only valid osd indices from primarytemp are used, and it falls back to using the primary from pgtemp or the up set if it is invalid.

[ idryomov: changelog ]

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

s390/vfioccw: Limit the number of channel program segments

The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program.

The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive.

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

sctp: validate cookie AUTH state before use

When cookie authentication is disabled, COOKIEECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays.

A forged RANDOM length can cause out-of-bounds reads during key-vector construction. A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain.

Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association. Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids.

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

netfilter: flowtable: publish GC-visible tuple last

nfflowtableiterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flowoffloadadd() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow.

KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rhtdeferredworker, jhash, flowoffloaddel, flowoffloadlookup, etc.).

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

macvlan: inherit neededheadroom and neededtailroom from lowerdev

macvlan devices inherit hardheaderlen from lowerdev during macvlaninit(), but leave neededheadroom and neededtailroom set to 0.

When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space.

This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when devhardheader() / macvlanhardheader() prepends header data or when lower devices append tailroom.

Fix this by: 1. Inheriting neededheadroom and neededtailroom from lowerdev in macvlaninit(). 2. Propagating neededheadroom and neededtailroom updates to attached macvlans in macvlandeviceevent() when receiving NETDEVFEATCHANGE events.

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

net: ethernet: ti: am65-cpsw-nuss: Fix portid extraction from SRC TAG

On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5descgettagsids() which fills in the 16-bit Source Tag into the 'portid' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid portid.

Hence, fix the portid extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID.

NVIDIA NemoClaw for Linux contains a vulnerability in its deployment process, where an attacker could cause improper certificate validation. A successful exploit of this vulnerability might lead to information disclosure, data tampering, code execution, and escalation of privileges.

NVIDIA OpenShell for Linux contains a vulnerability in its sandbox provisioning API, where an attacker could cause an incomplete list of disallowed inputs. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, information disclosure, data tampering, and denial of service.

NVIDIA NemoClaw for Linux contains a vulnerability in its installation process, where an attacker could cause execution of untrusted code. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, information disclosure, and denial of service.

NVIDIA NemoClaw for Linux contains a vulnerability in its remote-access helper workflow, where an attacker could cause weak authentication. A successful exploit of this vulnerability might lead to code execution, information disclosure, and data tampering.

NVIDIA OpenShell for Linux contains a vulnerability where an attacker could cause a sandbox escape. A successful exploit of this vulnerability might lead to code execution, escalation of privileges, data tampering, and information disclosure.

Adobe Campaign Classic (ACC) is affected by an Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability that could result in arbitrary code execution in the context of the current user. An attacker could exploit this vulnerability to execute arbitrary code. Exploitation of this issue does not require user interaction. Scope is changed.