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

net: openvswitch: fix overwriting ct original tuple for ICMPv6

OVSPACKETCMDEXECUTE has 3 main attributes: - OVSPACKETATTRKEY - Packet metadata in a netlink format. - OVSPACKETATTRPACKET - Binary packet content. - OVSPACKETATTRACTIONS - Actions to execute on the packet.

OVSPACKETATTRKEY is parsed first to populate swflowkey structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers.

Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet.

It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ctorig' that holds the original tuple conntrack metadata parsed from the OVSPACKETATTRKEY.

ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten.

The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace.

ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue.

Initializing the whole thing before parsing is needed because ND packet may not contain all the options.

The issue only affects the OVSPACKETCMDEXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed.

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

bnxten: Fix double DMA unmapping for XDPREDIRECT

Remove the dmaunmappageattrs() call in the driver's XDPREDIRECT code path. This should have been removed when we let the page pool handle the DMA mapping. This bug causes the warning:

WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommudmaunmappage+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G W 6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommudmaunmappage+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? showregs+0x6d/0x80 ? warn+0x89/0x150 ? iommudmaunmappage+0xd5/0x100 ? reportbug+0x16a/0x190 ? handlebug+0x51/0xa0 ? excinvalidop+0x18/0x80 ? iommudmaunmappage+0xd5/0x100 ? iommudmaunmappage+0x35/0x100 dmaunmappageattrs+0x55/0x220 ? bpfprog4d7e87c0d30db711xdpdispatcher+0x64/0x9f bnxtrxxdp+0x237/0x520 [bnxten] bnxtrxpkt+0x640/0xdd0 [bnxten] bnxtpollwork+0x1a1/0x3d0 [bnxten] bnxtpoll+0xaa/0x1e0 [bnxten] napipoll+0x33/0x1e0 netrxaction+0x18a/0x2f0

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:

net: stmmac: dwmac-tegra: Read iommu stream id from device tree

Nvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be written to the MGBEWRAPAXIASID0CTRL register.

The current driver is hard coded to use MGBE0's SID for all controllers. This causes softirq time outs and kernel panics when using controllers other than MGBE0.

Example dmesg errors when an ethernet cable is connected to MGBE1:

[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter. [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEMTYPEPAGEPOOL RxQ-0 [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171) [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 181.921198] rcu: INFO: rcupreempt detected stalls on CPUs/tasks: [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337 [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8) [ 181.921878] Sending NMI from CPU 4 to CPUs 7: [ 181.921886] NMI backtrace for cpu 7 [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6 [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024 [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 181.922847] pc : handlesoftirqs+0x98/0x368 [ 181.922978] lr : dosoftirq+0x18/0x20 [ 181.923095] sp : ffff80008003bf50 [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000 [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70 [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000 [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000 [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160 [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74 [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000 [ 181.967591] Call trace: [ 181.970043] handlesoftirqs+0x98/0x368 (P) [ 181.974240] dosoftirq+0x18/0x20 [ 181.977743] dosoftirq+0x14/0x28 [ 181.981415] callonirqstack+0x24/0x30 [ 181.985180] dosoftirqownstack+0x20/0x30 [ 181.989379] irqexitrcu+0x114/0x140 [ 181.993142] irqexitrcu+0x14/0x28 [ 181.996816] el1interrupt+0x44/0xb8 [ 182.000316] el1h64irqhandler+0x14/0x20 [ 182.004343] el1h64irq+0x80/0x88 [ 182.007755] cpuidleenterstate+0xc4/0x4a8 (P) [ 182.012305] cpuidleenter+0x3c/0x58 [ 182.015980] cpuidleidlecall+0x128/0x1c0 [ 182.020005] doidle+0xe0/0xf0 [ 182.023155] cpustartupentry+0x3c/0x48 [ 182.026917] secondarystartkernel+0xdc/0x120 [ 182.031379] secondaryswitched+0x74/0x78 [ 212.971162] rcu: INFO: rcupreempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/. [ 212.985935] rcu: blocking rcunode structures (internal RCU debug): [ 212.992758] Sending NMI from CPU 0 to CPUs 7: [ 212.998539] NMI backtrace for cpu 7 [ 213.004304] CPU: 7 UID: 0 PI ---truncated---

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

netfilter: socket: Lookup orig tuple for IPv6 SNAT

nfsklookupslowv4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socketmatch() can correctly check whether the socket was transparent.

However, the IPv6 counterpart (nfsklookupslowv6) lacks this conntrack lookup, making xtsocket fail to match on the socket when the packet was SNATed. Add the same logic to nfsklookupslowv6.

IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on -m socket --transparent and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.

bus: mhi: ep: Update read pointer only after buffer is written

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Iron Mountain Archiving Services Inc. EnVision allows Command Injection.

This issue affects enVision: before 250563.

A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This vulnerability allows a remote, unauthenticated attacker to execute arbitrary SQL commands via a specific ArcGIS Feature Service operation. Successful exploitation can potentially result in unauthorized access, modification, or deletion of data from the underlying Enterprise Geodatabase.

Sensitive data disclosure and manipulation due to improper authentication. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 39938, Acronis Cyber Protect 15 (Linux, Windows) before build 41800.

Sensitive data disclosure and manipulation due to improper authentication. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 39938, Acronis Cyber Protect 15 (Linux, Windows) before build 41800.

Sensitive data disclosure and manipulation due to missing authorization. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 39938, Acronis Cyber Protect 15 (Linux, Windows) before build 41800.

Adobe Campaign Classic (ACC) versions 7.4.3 build 9394 and earlier are affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in privilege escalation. Exploitation of this issue does not require user interaction. Scope is changed.

Adobe Campaign Classic (ACC) versions 7.4.3 build 9394 and earlier are affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue does not require user interaction. Scope is changed.

Adobe Campaign Classic (ACC) versions 7.4.3 build 9396 and earlier are affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue does not require user interaction. Scope is changed.

Chromium: CVE-2026-13782 Use after free in Browser

9p: avoid putting oldfid in p9clientwalk() error path

Adobe Campaign Classic (ACC) is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue does not require user interaction. Scope is changed.

Adobe Campaign Classic (ACC) is affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in privilege escalation. Exploitation of this issue does not require user interaction. Scope is changed.

Adobe Campaign Classic (ACC) is affected by an Improper Neutralization of Special Elements used in an SQL Command ('SQL 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 SQL commands, potentially gaining elevated access or control over the application. Exploitation of this issue does not require user interaction. Scope is changed.

Adobe Campaign Classic (ACC) is affected by an Improper Neutralization of Special Elements Used in a Template Engine 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.

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

geneve: validate inner network offset in genevegrocomplete()

Even with both paths gated on gs->grohint, genevegrocomplete() re-derives the inner dispatch type and length from the packet and the current gs->grohint, independently of genevegroreceive(). The two can disagree if gs->grohint flips under a concurrent genevequiesce()/ geneveunquiesce() (skuserdata is NULL across a synchronizenet()), or if the re-read option bytes differ from the ones receive parsed.

genevegroreceive() already records the inner network header position in NAPIGROCB()->innernetworkoffset. Have genevegrocomplete() compute the offset it is about to dispatch at, adding ETHHLEN in the ETHPTEB case where ethgrocomplete() steps over the inner MAC header, and bail out if it lands past innernetworkoffset.

Use a lower bound rather than exact equality: between ghlen and the inner L3 header, genevegroreceive() may also have pulled an inner VLAN tag (vlangroreceive() advances the recorded offset past it), which only moves innernetworkoffset further out. A valid frame therefore always satisfies innernh <= innernetworkoffset, while a ghlen inflated by a hint groreceive() did not honour dispatches past the validated inner header, i.e. the out-of-bounds completion. Only the latter is rejected.

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

geneve: gate GRO hint in genevegrocomplete() on gs->grohint

genevegroreceive() reads the GRO hint through geneveskgrohintoff(), which honours it only when the socket enabled IFLAGENEVEGROHINT (gs->grohint). genevegrocomplete() instead calls the low-level geneveoptgrohintoff() and acts on the hint unconditionally.

On a tunnel without the hint, receive aggregates the frames as plain ETHPTEB while complete still honours an attacker-supplied hint option: it inflates ghlen by grohint->nestedhdrlen (u8) and redirects the dispatch type, so the inner grocomplete handler runs at nhoff + ghlen, an offset receive never pulled nor validated, reading out of bounds of the skb head:

BUG: KASAN: slab-out-of-bounds in ipv6grocomplete (net/ipv6/ip6offload.c:196) Read of size 1 at addr ffff88800fe91980 by task exploit/153 ipv6grocomplete (net/ipv6/ip6offload.c:196) genevegrocomplete (drivers/net/geneve.c:965) udpgrocomplete (net/ipv4/udpoffload.c:940) inetgrocomplete (net/ipv4/afinet.c:1621) groflush (net/core/gro.c:306)

Gate the complete path on gs->grohint too via geneveskgrohintoff(), so both paths agree. Tunnels that enable the hint are unaffected.

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

ipv4: fib: Don't ignore error route in local/main tables.

When CONFIGIPMULTIPLETABLES is enabled but no rule is added, fiblookup() performs route lookup directly on two tables.

Since the first lookup does not properly bail out, the result of an error route in the merged local/main table could be overwritten by another route in the default table:

# unshare -n # ip link set lo up # ip route add 192.168.0.0/24 dev lo table 253 # ip route add unreachable 192.168.0.0/24 # ip route get 192.168.0.1 192.168.0.1 dev lo table default uid 0 cache <local>

Once a random rule is added, the error route is respected:

# ip rule add table 0 # ip rule del table 0 # ip route get 192.168.0.1 RTNETLINK answers: No route to host

Let's fix the inconsistent behaviour.

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

vdpa/octeonep: fix IRQ-to-ring mapping in interrupt handler

Look up the IRQ index in octhw->irqs instead of assuming irq - irqs[0]. This supports non-contiguous IRQ numbers and avoids incorrect ring indexing when irqs[0] is not the base.

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

crypto: cavium/cpt - fix DMA cleanup using wrong loop index

The sgcleanup error path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.

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

vxlan: use neighhasnapshot() in routeshortcircuit()

The neighbour hardware address n->ha can be updated asynchronously by the neighbour subsystem, protected by n->halock seqlock. Reading n->ha without holding the seqlock loop can lead to torn reads or reading a partially updated MAC address.

Use neighhasnapshot() in routeshortcircuit() to safely copy n->ha under readseqbegin()/readseqretry() lock protection before using it.

Note that arpreduce() and neighreduce() seem to have the same issue left for future patches.

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

veth: fix skb length accounting after XDP frag adjustment

veth exposes non-linear skb fragments through an xdpbuff. If an XDP program adjusts the fragment area, vethxdprcvskb() copies xdpfragssize back to skb->datalen but leaves skb->len containing the old fragment contribution.

After a fragment shrink, this makes skbheadlen() larger than the actual linear area. In the reproduced UDP receive path, skbdatagramiter() copied 1024 bytes past the actual linear tail to userspace, starting at struct skbsharedinfo. The copied bytes included the affected skb's nrfrags, xdpfragssize, and a kernel pointer from skbshinfo(skb)->frags[0]. Real packet data was displaced by the same amount and truncated at the end.

Subtract the old datalen before replacing it and add the new datalen afterwards, keeping skb->len and skb->datalen synchronized.

Additionally, bpfxdppulldata() can advance dataend while leaving frags present. The skb is then still non-linear, so the old skbput(skb, off) triggers SKBLINEARASSERT().

Use skbsettailpointer() and update skb->len explicitly instead, following bpfprogrungenericxdp(). Unlike skbput(), skbsettailpointer() does not require a linear skb.

A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by 1024 bytes from its fragment area. Before the fix, all 10 runs produced corrupted payloads. After the fix, all 10 runs matched the expected payload exactly. A forced-tailroom reproducer also exercises bpfxdppulldata() with frags still present; the old code triggers SKBLINEARASSERT(), while this fix passes 10/10 runs.

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.

Adobe Campaign Classic (ACC) is affected by a Server-Side Request Forgery (SSRF) 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.

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.