All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-cve-announce@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@kernel.org>
Subject: CVE-2026-80840: ipv6: seg6: clear IPv4 control block on IPIP decapsulation
Date: Fri,  4 Sep 2026 17:53:07 +0200	[thread overview]
Message-ID: <2026090457-CVE-2026-80840-54d7@gregkh> (raw)

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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

ipv6: seg6: clear IPv4 control block on IPIP decapsulation

End.DX4 and End.DT4 decapsulate an IPv4 packet through
decap_and_validate() and send it directly to IPv4 routing. The inner
packet therefore bypasses ip_rcv_core(), which normally clears IPCB
before IPv4 interprets skb->cb.

The skb instead retains IP6CB data from the outer packet. IP6CB and
IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps
IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and
ts.

The sender can make the stale optlen byte nonzero with a valid outer
extension-header chain. The reproducers put an eight-byte Destination
Options header immediately after the 40-byte IPv6 header and before the
Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled
Destination Options offset in both lastopt and nhoff, setting them to
40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees
optlen = 40 and rr = 40.

Both tcp_v4_save_options() and __ip_options_echo() skip option copying
when optlen is zero. Here optlen is 40, so the TCP SYN path allocates
room for 40 bytes of option data and calls __ip_options_echo(). The
stale rr value makes that function read inner packet byte 41 as the
Record Route option length. The reproducers set that sender-controlled
byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte
option-data area.

Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5
kernel both produced:

  BUG: KASAN: slab-out-of-bounds in __ip_options_echo()
  Write of size 255

The relevant End.DX4 call path is:

  __ip_options_echo
  tcp_v4_route_req
  tcp_conn_request
  tcp_v4_conn_request
  tcp_rcv_state_process
  tcp_v4_do_rcv
  tcp_v4_rcv
  ip_protocol_deliver_rcu
  ip_local_deliver_finish
  ip_local_deliver
  input_action_end_dx4_finish
  input_action_end_dx4

The relevant End.DT4 call path is:

  __ip_options_echo
  tcp_v4_route_req
  tcp_conn_request
  tcp_v4_conn_request
  tcp_rcv_state_process
  tcp_v4_do_rcv
  tcp_v4_rcv
  ip_protocol_deliver_rcu
  ip_local_deliver_finish
  ip_local_deliver
  input_action_end_dt4

tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so
it does not appear as a separate frame.

When decap_and_validate() handles IPPROTO_IPIP, save the ingress
interface from IP6CB, clear IPCB, and restore the saved value. Doing
this in the common decapsulation path covers End.DX4, End.DT4, and
End.DT46's IPv4 arm.

Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after
l3mdev processing, which can replace skb_iif with the L3 master;
IP6CB iif still records the receiving interface set at IPv6 ingress.

The Linux kernel CVE team has assigned CVE-2026-80840 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 5.10.269 with commit 10fd1a8f58ac619a9e251f2858e2e2c8fd6cd667
	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 5.15.220 with commit eb0f422487228e140f3d609b032ac61aedcab8fa
	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 6.1.187 with commit 9039e4f3e1c0ffe2b575b655b3f58fdd10f7e40c
	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 6.6.156 with commit f52f1e75716d2ee49e013edf204ac92337c72fd8
	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 6.12.108 with commit 0e3f01fe2e704e76af4385b8a1742641885a191c
	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 6.18.49 with commit 3e4476e58343fb8f2fffced9e22d935376b17aaf
	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 7.1.13 with commit bf1c1151560d11036a144d917fa4c131831342d7
	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 7.2.3 with commit f4be3b391265e24c7720fc867c50062b436acf33
	Issue introduced in 4.14 with commit 891ef8dd2a8d14e4e73a81dcdb135b574c57f556 and fixed in 7.3-rc1 with commit 44930446dde45a7a90fe1446fa38eb0e2c561646

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-80840
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/ipv6/seg6_local.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/10fd1a8f58ac619a9e251f2858e2e2c8fd6cd667
	https://git.kernel.org/stable/c/eb0f422487228e140f3d609b032ac61aedcab8fa
	https://git.kernel.org/stable/c/9039e4f3e1c0ffe2b575b655b3f58fdd10f7e40c
	https://git.kernel.org/stable/c/f52f1e75716d2ee49e013edf204ac92337c72fd8
	https://git.kernel.org/stable/c/0e3f01fe2e704e76af4385b8a1742641885a191c
	https://git.kernel.org/stable/c/3e4476e58343fb8f2fffced9e22d935376b17aaf
	https://git.kernel.org/stable/c/bf1c1151560d11036a144d917fa4c131831342d7
	https://git.kernel.org/stable/c/f4be3b391265e24c7720fc867c50062b436acf33
	https://git.kernel.org/stable/c/44930446dde45a7a90fe1446fa38eb0e2c561646

                 reply	other threads:[~2026-09-04 15:57 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026090457-CVE-2026-80840-54d7@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=cve@kernel.org \
    --cc=gregkh@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.