linux-stable.git, branch linux-rolling-lts

Merge v6.18.48

2026-08-28T06:22:54+00:00

Signed-off-by: Greg Kroah-Hartman

Linux 6.18.48

2026-08-28T06:22:54+00:00

Signed-off-by: Greg Kroah-Hartman

inet: frags: strip GSO state from fragments before reassembly

2026-08-28T06:22:54+00:00

commit d5dc1e69fd7258ea605c9952e5d5947539159ae3 upstream.

A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark
an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off.
inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first
fragment's skb as the head of the reassembled datagram, including its
shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments
on frag_list with whatever linear/paged layout they arrived with.

After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the
reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and
the next software segmentation point - udp_rcv_segment() on local
delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow
path - hands it to skb_segment(). skb_segment()'s frag_list walk
assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to
a tap by an unprivileged user in its own userns are enough:

  kernel BUG at net/core/skbuff.c:4899!
  Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
  CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2
  RIP: 0010:skb_segment+0x20ca/0x48b0
  Call Trace:
   
   __udp_gso_segment+0x29a/0x27d0
   udp4_ufo_fragment+0x458/0x6c0
   inet_gso_segment+0x429/0x1340
   skb_mac_gso_segment+0x233/0x4f0
   __skb_gso_segment+0x308/0x660
   udp_queue_rcv_skb+0x440/0xad0
   udp_unicast_rcv_skb+0xc7/0x2c0
   udp_rcv+0x16ce/0x2260
   ip_protocol_deliver_rcu+0x197/0x2d0
   ip_local_deliver+0x430/0x690
   ip_rcv+0x16f/0x1f0
   __netif_receive_skb_one_core+0x15e/0x1c0
   __netif_receive_skb+0x1e/0x110
   netif_receive_skb+0xf6/0x5c0
   tun_rx_batched.isra.0+0x3ab/0x790
   tun_get_user+0x17c3/0x3550
   tun_chr_write_iter+0xba/0x1b0
   vfs_write+0x646/0x1130
   
  Kernel panic - not syncing: Fatal exception in interrupt

This runs with BH disabled, so it is a panic rather than an oops. The
same is reachable with CAP_NET_RAW in a netns where a defrag point
precedes a GSO point, and from a guest whose VMM forwards
virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by
commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting
gso_size mangled skb having linear-headed frag_list") and by
commit 9e4b7a99a03a ("net: gso: fix panic on frag_list with mixed head
alloc types") do not cover it: page-backed heads skip them, and kmalloc
heads skip them when gso_size == skb_headlen(head), which the sender
controls.

An skb entering a frag queue is an IP fragment by definition and
cannot legitimately carry GSO state: GRO does not merge fragments and
the stack segments before it fragments, so only untrusted sources are
affected. This has been reachable since
commit f43798c27684 ("tun: Allow GSO using virtio_net_hdr"), the first
path that let userspace attach GSO metadata to an IP fragment. Reset
the GSO fields of every fragment as it is queued, in
inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and
6lowpan reassembly share; then neither the head nor the frag_list
members of the reassembled skb carry them (the members matter too:
the ip_do_fragment()/ip6_fragment() fast paths send them out as they
are). The head may remain CHECKSUM_PARTIAL; that is already accepted
on receive and resolved by skb_checksum_help() in
ip_do_fragment()/ip6_fragment() on forward.

Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer
above, two further IPv4 frag_list geometries that reach
BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6
fragment-header variant (udp6_ufo_fragment()) each panic the unpatched
kernel; with this patch all four datagrams are delivered intact and
nothing is logged.

Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
Cc: stable@kernel.org
Suggested-by: Eric Dumazet 
Signed-off-by: Xinyang Ge 
Signed-off-by: Paolo Abeni 
Reviewed-by: Eric Dumazet 
Link: https://patch.msgid.link/937926e509f2acd8e0e66520dc2b30fd6b4d1687.1787839506.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

Merge v6.18.47

2026-08-27T12:32:55+00:00

Signed-off-by: Greg Kroah-Hartman

Linux 6.18.47

2026-08-27T12:32:55+00:00

Link: https://lore.kernel.org/r/20260825132541.887883084@linuxfoundation.org
Tested-by: Pavel Machek (CIP) 
Tested-by: Florian Fainelli 
Tested-by: Shuah Khan 
Tested-by: Ron Economos 
Tested-by: Wentao Guan 
Tested-by: Brett A C Sheffield 
Tested-by: Miguel Ojeda 
Tested-by: Peter Schneider 
Signed-off-by: Greg Kroah-Hartman

net: gro: properly validate BIG TCP aggregation criteria

2026-08-27T12:32:55+00:00

When GRO attempts to aggregate packets beyond GRO_LEGACY_MAX_SIZE (64KB),
BIG TCP should only be permitted for plain IPv4 TCP and plain IPv6 TCP
(with sufficient MAC header room to insert the temporary HBH jumbo header).

However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp")
loosened the check in skb_gro_receive(), leading to several issues:

1. skb_gro_receive() checked skb_headroom(p) instead of the actual space
   before the MAC header (p->mac_header). Because skb_headroom(p) includes
   mac_len, crafted frames (e.g. injected via AF_PACKET) can pass the check
   with p->mac_header < 8 bytes. When ipv6_gro_complete() inserts the
   temporary HBH jumbo header, the memmove() starts before skb->head,
   causing an out-of-bounds write and wrapping skb->mac_header.
2. It allowed non-IP protocols such as software VLAN (ETH_P_8021Q /
   ETH_P_8021AD) to aggregate beyond 64KB because
   p->protocol != ETH_P_IPV6 was true.
3. It checked p->encapsulation instead of NAPI_GRO_CB(skb)->encap_mark,
   allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate
   beyond 64KB.

Fix skb_gro_receive() to strictly enforce:
- NAPI_GRO_CB(skb)->proto == IPPROTO_TCP
- Not encapsulated (!NAPI_GRO_CB(skb)->encap_mark && !p->encapsulation)
- Protocol must be either ETH_P_IP or ETH_P_IPV6
- If ETH_P_IPV6, p->mac_header must be at least
  sizeof(struct hop_jumbo_hdr)

Returning -E2BIG from skb_gro_receive() ensures that packets which cannot
become BIG TCP are cleanly flushed at <= 64KB and delivered intact without
dropping.

This issue does not exist in mainline (7.0+) because the subsystem was
rewritten in commit 81be30c1f5f2 ("net/ipv6: Drop HBH for BIG TCP on RX
side"), making this fix relevant only for older stable branches like
6.18.y.

Fixes: 0fe79f28bfaf ("net: allow gro_max_size to exceed 65536")
Fixes: b1a78b9b9886 ("net: add support for ipv4 big tcp")
Reported-by: Sam Dlinn 
Cc: stable@vger.kernel.org
Signed-off-by: Eric Dumazet 
Signed-off-by: Greg Kroah-Hartman

ptp: vmclock: prevent read-only mappings from becoming writable

2026-08-27T12:32:55+00:00

commit a5edadbae57e2298a56cf7a4e774a027905a331f upstream.

vmclock_miscdev_mmap() rejects writable mappings of the shared vmclock
ABI page with -EROFS, but leaves VM_MAYWRITE set.  Userspace can map the
page read-only and then upgrade it to writable with mprotect(), after
which the guest can corrupt the host-written timekeeping data (sequence
counter, UTC time, TSC offset) that the vmclock ABI defines as read-only.

Clear VM_MAYWRITE on the read-only path so the mapping cannot be
upgraded, as i915 does for its read-only objects and as fixed in drm/vc4
(CVE-2026-68445) and drm/panthor (CVE-2024-53071).

Cc: stable@vger.kernel.org
Fixes: 205032724226 ("ptp: Add support for the AMZNC10C 'vmclock' device")
Signed-off-by: Abdifatah Suruur 
Link: https://patch.msgid.link/20260813174707.14809-1-suruurism@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

futex: Avoid private hash use-after-free on final put

2026-08-27T12:32:55+00:00

[ Upstream commit 1c7efabfbaf796f11000a46094a69955a01ec6cc ]

futex_private_hash_put() drops the reference to fph before evaluating
fph->mm for wake_up_var(). futex_ref_put() enables preemption again before
returning. If that put drops the final reference and the task is preempted,
another task can pivot to the replacement hash and free the old hash after
an RCU grace period. The first task then reads fph->mm from the freed
allocation when it resumes.

KASAN reports a slab-use-after-free in futex_private_hash_put(), with the
read at offset 24 in a freed kmalloc-512 allocation. The allocation and
free stacks point to futex_hash_allocate() and the RCU free path,
respectively.

Load the mm pointer while the fph reference is still held and pass the
saved value to wake_up_var(). wake_up_var() uses the pointer as a waitqueue
key and does not dereference the mm through it.

Fixes: bd54df5ea7ca ("futex: Allow to resize the private local hash")
Signed-off-by: Felix Hoffmann 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260731155024.1150011-1-f3lix.dev@gmx.de
[ dropped the `!fph` NULL guard since this tree's callers already check, keeping the existing `if (futex_ref_put(fph))` form ]
Signed-off-by: Sasha Levin

Bluetooth: hci_aml: validate firmware segment lengths

2026-08-27T12:32:55+00:00

commit 2bf6b9baca9372ea51b6d0f2820dc9bf29a83ef4 upstream.

aml_download_firmware() reads two lengths from the firmware header and
uses them to build pointers before checking that the header and segment
data are present. A truncated or inconsistent firmware image can make
the driver read past firmware->data while constructing TCI commands.

Reject images shorter than the header and ensure that the ICCM and DCCM
ranges fit within the loaded firmware before downloading either segment.

Fixes: 37bac77e4649 ("Bluetooth: hci_uart: Add support for Amlogic HCI UART")
Cc: stable@vger.kernel.org
Signed-off-by: Laxman Acharya Padhya 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: MGMT: reject HCI_CMD_SYNC params_len above 255

2026-08-27T12:32:54+00:00

commit 5d95286b6d6e8f1d304da7522bfa6860fc017e48 upstream.

mgmt_hci_cmd_sync() checks that the message length agrees with params_len
but puts no upper bound on it. params_len is __le16 while the parameter
length in the HCI command header is a u8:

	struct hci_command_hdr {
		__le16	opcode;
		__u8	plen;
	} __packed;

hci_cmd_sync_alloc() assigns one to the other:

	hdr->plen = plen;

	if (plen)
		skb_put_data(skb, param, plen);

so a params_len of 256 leaves plen at 0 while all 256 bytes are still
appended. The frame handed to the driver then declares no parameters and
carries 256 of them. On a length framed transport such as H:4 the
controller takes the trailing bytes as the start of the next packet.

The mgmt socket MTU is HCI_MAX_FRAME_SIZE, so params_len can reach about
1KB this way. Commit 03f1700b9b4d ("Bluetooth: MGMT: reject malformed
HCI_CMD_SYNC commands") only made params_len agree with the message
length, a value that fits the message but not the header field is still
accepted.

Reject params_len that does not fit the header field.

Fixes: 827af4787e74 ("Bluetooth: MGMT: Add initial implementation of MGMT_OP_HCI_CMD_SYNC")
Cc: stable@vger.kernel.org
Signed-off-by: Ali Ahmet Memis 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman