[PATCH AUTOSEL 7.0-5.15] wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation

[PATCH AUTOSEL 7.0-5.15] wifi: nl80211: re-check wiphy netns in nl80211_prepare_wdev_dump() continuation

[Sasha Levin]

From: Maoyi Xie <maoyi.xie@ntu.edu.sg>

[ Upstream commit 79240f3f6d766b342b57c32397d643e1cfa26b81 ]

NL80211_CMD_GET_SCAN is implemented as a multi-call dumpit. The first
invocation of nl80211_prepare_wdev_dump() validates the requested wdev
against the caller's netns via __cfg80211_wdev_from_attrs(). Subsequent
invocations look up the same wiphy by its global index and do not check
that the wiphy is still in the caller's netns.

Add the same filter to the continuation path. If the wiphy's netns no
longer matches the caller's, return -ENODEV and the netlink dump
machinery terminates the walk cleanly.

Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260506064854.2207105-3-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

**Phase 1: Commit Message Forensics**
- Step 1.1 Record: Subsystem `wifi: nl80211`; action verb `re-check`;
  intent is to revalidate the wiphy net namespace during
  `nl80211_prepare_wdev_dump()` continuation.
- Step 1.2 Record: Tags are `Signed-off-by: Maoyi Xie`, `Link: https://p
  atch.msgid.link/20260506064854.2207105-3-maoyixie.tju@gmail.com`,
  `Signed-off-by: Johannes Berg`. No `Fixes`, `Reported-by`, `Tested-
  by`, `Reviewed-by`, `Acked-by`, or `Cc: stable`.
- Step 1.3 Record: The committed message says first dump invocation
  validates via `__cfg80211_wdev_from_attrs()`, but later invocations
  recover the wiphy by global index and lacked a netns check. The v3
  mailing-list patch further states the failure mode: BSS scan data can
  continue being copied from a wiphy after it moved to another netns.
- Step 1.4 Record: This is a hidden security/correctness fix, not a
  cleanup. It fixes a namespace isolation race in a multi-call netlink
  dump.

**Phase 2: Diff Analysis**
- Step 2.1 Record: One file changed, `net/wireless/nl80211.c`; commit
  stat is 12 insertions. One function changed:
  `nl80211_prepare_wdev_dump()`. Scope is single-file surgical.
- Step 2.2 Record: Before, continuation path did
  `wiphy_idx_to_wiphy(cb->args[0] - 1)`, accepted the wiphy, then
  searched `wdev_list`. After, it returns `-ENODEV` if
  `!net_eq(wiphy_net(wiphy), sock_net(cb->skb->sk))`.
- Step 2.3 Record: Bug category is race / namespace isolation /
  information disclosure. A wiphy can move netns between dumpit calls
  via `NL80211_CMD_SET_WIPHY_NETNS`.
- Step 2.4 Record: Fix quality is high: one predicate and clean error
  return before taking `wiphy.mtx`. Regression risk is low; it only
  rejects a continuation whose object no longer belongs to the caller’s
  netns.

**Phase 3: Git History**
- Step 3.1 Record: Current checkout is shallow; `git blame` attributed
  the region to a shallow boundary, so that blame is not reliable.
  Pickaxe history found the continuation-by-global-wiphy-index pattern
  in old history, including `c319d50bfcf67` (`nl80211: fix another
  nl80211_fam.attrbuf race`), contained by `v3.11-rc6`. Netns support
  for cfg80211/nl80211 was introduced by `463d018323851`, contained by
  `v2.6.32-rc1`.
- Step 3.2 Record: No `Fixes:` tag, so no tagged introducer to follow.
- Step 3.3 Record: Fetched wireless history shows the candidate
  immediately follows companion commit `15994bb0cbb8f` (`wifi: nl80211:
  require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS`). No
  intermediate commit between them.
- Step 3.4 Record: Author has only these two fetched wireless commits.
  Committer is Johannes Berg, the nl80211/cfg80211 maintainer.
- Step 3.5 Record: No compile dependency on the companion commit, but
  logical/security context is stronger if `15994bb0cbb8f` is backported
  too.

**Phase 4: Mailing List / External Research**
- Step 4.1 Record: `b4 dig -c 79240f3f6d766...` found the v3 patch at
  the provided `patch.msgid.link` URL. `b4 dig -a` found v1 and v3; `b4
  am` showed v1, v2, v3. v3 cover says no code changes since v2 and that
  Johannes review caused comment/trailer cleanup.
- Step 4.2 Record: `b4 dig -w` shows Johannes Berg, `linux-wireless`,
  and `linux-kernel` were included.
- Step 4.3 Record: No syzbot/bugzilla report. The series cover and patch
  body provide the bug explanation and patch 1 includes a mac80211_hwsim
  reproducer for the related `SET_WIPHY_NETNS` privilege path.
- Step 4.4 Record: This is patch 2/2 in a series. Patch 1 hardens
  target-netns capability checks; patch 2 fixes dump continuation
  filtering.
- Step 4.5 Record: Lore WebFetch was blocked by Anubis; WebSearch did
  not find stable-specific discussion.

**Phase 5: Code Semantic Analysis**
- Step 5.1 Record: Modified function is `nl80211_prepare_wdev_dump()`.
- Step 5.2 Record: Exact callers are `nl80211_dump_station()`,
  `nl80211_dump_mpath()`, `nl80211_dump_mpp()`, `nl80211_dump_scan()`,
  and `nl80211_dump_survey()`.
- Step 5.3 Record: Key callees are `__cfg80211_wdev_from_attrs()`,
  `wiphy_idx_to_wiphy()`, `wiphy_net()`, `sock_net()`, `net_eq()`,
  `wiphy_to_rdev()`, and list walk over `wiphy.wdev_list`.
- Step 5.4 Record: `NL80211_CMD_GET_SCAN` maps to `nl80211_dump_scan()`
  and has no admin flag in the ops entry; `NL80211_CMD_SET_WIPHY_NETNS`
  maps to `nl80211_wiphy_netns()` with `GENL_UNS_ADMIN_PERM`.
- Step 5.5 Record: Similar dump paths `nl80211_dump_wiphy()` and
  `nl80211_dump_interface()` already filter by `net_eq(wiphy_net(...),
  sock_net(skb->sk))` each iteration.

**Phase 6: Stable Tree Analysis**
- Step 6.1 Record: The affected continuation code exists in checked tags
  `v6.19`, `v6.18`, `v6.12`, `v6.6`, `v6.1`, `v5.15`, `v5.10`, `v5.4`,
  `v4.19`, and `v4.14`.
- Step 6.2 Record: Modern stable trees have the same helper shape. Older
  trees such as `v5.4` and `v4.14` have different function
  signatures/locking, so they may need small backport adjustment.
- Step 6.3 Record: Searches in checked stable tags did not find this
  candidate or the companion commit already present.

**Phase 7: Subsystem Context**
- Step 7.1 Record: Subsystem is wireless cfg80211/nl80211, an important
  networking control-plane subsystem.
- Step 7.2 Record: `net/wireless/nl80211.c` is actively maintained;
  fetched wireless history shows this series was taken through Johannes
  Berg’s wireless tree.

**Phase 8: Impact / Risk**
- Step 8.1 Record: Affected users are systems using wireless devices
  with nl80211 netns movement support, including delegated/container
  wireless setups and mac80211_hwsim.
- Step 8.2 Record: Trigger requires a multi-call dump and a wiphy netns
  move between invocations. The related series verifies an unprivileged
  userns path when the caller has a delegated `WIPHY_FLAG_NETNS_OK`
  wiphy.
- Step 8.3 Record: Failure mode is namespace isolation breach / cross-
  netns scan-result exposure, not a crash. Severity: HIGH due
  security/isolation impact.
- Step 8.4 Record: Benefit is high for isolation correctness; risk is
  very low because the patch adds one local validation and returns an
  existing error code.

**Phase 9: Final Synthesis**
- Step 9.1 Record: Evidence for backporting: real namespace isolation
  bug, old code present across stable trees, small surgical fix,
  maintainer-applied, aligns with existing dump filtering. Evidence
  against: companion patch should also be considered, and older trees
  may require minor backport edits. Unresolved: no independent `Tested-
  by`; stable-specific lore discussion could not be fetched.
- Step 9.2 Record: Stable rules: obviously correct yes; fixes real bug
  yes; important issue yes due namespace isolation/security; small and
  contained yes; no new API/feature yes; applies cleanly or with minor
  adjustment depending on tree.
- Step 9.3 Record: No exception category applies.
- Step 9.4 Record: Backport is warranted, preferably together with
  `15994bb0cbb8f` for the complete netns hardening series.

## Verification
- Phase 1: Parsed `git show 79240f3f6d766...` and b4 v3 patch text;
  verified tags and commit body.
- Phase 2: Verified diff is one hunk in `nl80211_prepare_wdev_dump()`
  with 12 insertions.
- Phase 3: Ran `git blame`, pickaxe history, `git show` for
  `c319d50bfcf67`, `463d018323851`, companion `15994bb0cbb8f`, and
  fetched wireless history.
- Phase 4: Ran `b4 dig`, `b4 dig -a`, `b4 dig -w`, `b4 am` for v1/v2/v3,
  saved/read mbox; WebFetch to lore was blocked by Anubis.
- Phase 5: Verified callers and relevant ops entries in
  `net/wireless/nl80211.c`.
- Phase 6: Used `git grep` across stable tags to confirm affected code
  exists and checked stable logs for absence of the candidate.
- Phase 8: Severity is based on verified patch text plus code paths; no
  build or runtime test was run.

**YES**

 net/wireless/nl80211.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b94231c8441c4..ce3121b1c3319 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1146,6 +1146,18 @@ static int nl80211_prepare_wdev_dump(struct netlink_callback *cb,
 			rtnl_unlock();
 			return -ENODEV;
 		}
+
+		/*
+		 * The first invocation validated the wdev's netns against
+		 * the caller via __cfg80211_wdev_from_attrs(). The wiphy
+		 * may have moved netns between dumpit invocations (via
+		 * NL80211_CMD_SET_WIPHY_NETNS), so re-check here.
+		 */
+		if (!net_eq(wiphy_net(wiphy), sock_net(cb->skb->sk))) {
+			rtnl_unlock();
+			return -ENODEV;
+		}
+
 		*rdev = wiphy_to_rdev(wiphy);
 		*wdev = NULL;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ipv6: Implement limits on extension header parsing

[Sasha Levin]

From: Daniel Borkmann <daniel@iogearbox.net>

[ Upstream commit 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac ]

ipv6_{skip_exthdr,find_hdr}() and ip6_{tnl_parse_tlv_enc_lim,
protocol_deliver_rcu}() iterate over IPv6 extension headers until they
find a non-extension-header protocol or run out of packet data. The
loops have no iteration counter, relying solely on the packet length
to bound them. For a crafted packet with 8-byte extension headers
filling a 64KB jumbogram, this means a worst case of up to ~8k
iterations with a skb_header_pointer call each. ipv6_skip_exthdr(),
for example, is used where it parses the inner quoted packet inside
an incoming ICMPv6 error:

  - icmpv6_rcv
    - checksum validation
    - case ICMPV6_DEST_UNREACH
      - icmpv6_notify
        - pskb_may_pull()       <- pull inner IPv6 header
        - ipv6_skip_exthdr()    <- iterates here
        - pskb_may_pull()
        - ipprot->err_handler() <- sk lookup

The per-iteration cost of ipv6_skip_exthdr itself is generally
light, but skb_header_pointer becomes more costly on reassembled
packets: the first ~1232 bytes of the inner packet are in the skb's
linear area, but the remaining ~63KB are in the frag_list where
skb_copy_bits is needed to read data.

Initially, the idea was to add a configurable limit via a new
sysctl knob with default 8, in line with knobs from commit
47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination
options"), but two reasons eventually argued against it:

- It adds to UAPI that needs to be maintained forever, and
  upcoming work is restricting extension header ordering anyway,
  leaving little reason for another sysctl knob
- exthdrs_core.c is always built-in even when CONFIG_IPV6=n,
  where struct net has no .ipv6 member, so the read site would
  need an ifdef'd fallback to a constant anyway

Therefore, just use a constant (IP6_MAX_EXT_HDRS_CNT). All four
extension header walking functions are now bound by this limit.

Note that the check in ip6_protocol_deliver_rcu() happens right
before the goto resubmit, such that we don't have to have a test
for ipv6_ext_hdr() in the fast-path.

There's an ongoing IETF draft-iurman-6man-eh-occurrences to enforce
IPv6 extension headers ordering and occurrence. The latter also
discusses security implications. As per RFC8200 section 4.1, the
occurrence rules for extension headers provide a practical upper
bound which is 8. In order to be conservative, let's define
IP6_MAX_EXT_HDRS_CNT as 12 to leave enough room for quirky setups.
In the unlikely event that this is still not enough, then we might
need to reconsider a sysctl.

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Link: https://patch.msgid.link/20260429154648.809751-1-daniel@iogearbox.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This should be backported. It is a small IPv6 networking hardening/fix
for a reachable CPU-exhaustion path: several IPv6 extension-header
walkers were bounded only by packet length, allowing crafted packets
with many minimal 8-byte extension headers to force thousands of
iterations. The patch caps traversal at 12 headers, avoids new UAPI, and
was reviewed by IPv6/networking reviewers. Risk is mainly dropping
extremely exotic packets with more than 12 extension headers; the review
discussion explicitly considered that and settled on 12 as a
conservative compromise.

## Phase Walkthrough
Phase 1: Commit Message Forensics

Record 1.1: Subsystem `ipv6`; action verb `Implement limits`; claimed
intent is to bound IPv6 extension-header parsing loops.

Record 1.2: Tags found: `Signed-off-by: Daniel Borkmann`, `Reviewed-by:
Ido Schimmel`, `Reviewed-by: Eric Dumazet`, `Reviewed-by: Justin
Iurman`, `Link:
https://patch.msgid.link/20260429154648.809751-1-daniel@iogearbox.net`,
`Signed-off-by: Jakub Kicinski`. No `Fixes:`, no `Reported-by:`, no `Cc:
stable`.

Record 1.3: The body describes crafted 64KB packets with 8-byte
extension headers causing up to about 8k iterations, with costly
`skb_header_pointer()`/`skb_copy_bits()` on reassembled packets. Symptom
is CPU work amplification/DoS potential, not memory corruption or crash.
It identifies `icmpv6_rcv -> icmpv6_notify -> ipv6_skip_exthdr()` as a
concrete path.

Record 1.4: This is not disguised cleanup. It is a direct
correctness/security hardening fix: add a bound to previously unbounded
loops.

Phase 2: Diff Analysis

Record 2.1: Five files changed, 25 insertions: `include/net/dropreason-
core.h` +6, `include/net/ipv6.h` +3, `net/ipv6/exthdrs_core.c` +7,
`net/ipv6/ip6_input.c` +5, `net/ipv6/ip6_tunnel.c` +4. Modified
functions: `ipv6_skip_exthdr()`, `ipv6_find_hdr()`,
`ip6_protocol_deliver_rcu()`, `ip6_tnl_parse_tlv_enc_lim()`.

Record 2.2: Before, these loops stopped only at non-extension-header,
`NEXTHDR_NONE`, malformed/truncated packet data, fragment handling, or
protocol handler completion. After, each loop also stops/drops once
`IP6_MAX_EXT_HDRS_CNT` is exceeded.

Record 2.3: Bug category is logic/performance DoS hardening: missing
iteration bound in packet parser. It does not fix UAF/leak/race, but it
prevents attacker-controlled excessive parsing work.

Record 2.4: Fix quality is good: small, local counters, no locking or
lifetime changes, no new sysctl/API. Regression risk is limited to
rejecting packets with more than 12 traversed extension headers.

Phase 3: Git History Investigation

Record 3.1: `git blame` shows the relevant loops are old:
`ipv6_skip_exthdr()` loop traces to initial/early history with later
signature changes; `ipv6_find_hdr()` to v3.8-era code;
`ip6_protocol_deliver_rcu()` resubmit logic to v4.x/v5.0-era changes;
`ip6_tnl_parse_tlv_enc_lim()` exists from initial/older tunnel code with
later cleanups.

Record 3.2: No `Fixes:` tag, so no introducing commit to follow. I did
inspect referenced commit `47d3d7ac656a`, which added limits for Hop-by-
Hop/Destination TLV parsing and described similar DoS behavior.

Record 3.3: Recent file history shows related commit `076b8cad77aa9`
capped TLV scanning in `ip6_tnl_parse_tlv_enc_lim()`. This commit is
related but not a hard dependency for the outer extension-header-count
limit.

Record 3.4: Daniel Borkmann has recent related IPv6 limit work in the
same area. Commit was applied by Jakub Kicinski, and reviewed by Eric
Dumazet, Ido Schimmel, and Justin Iurman.

Record 3.5: No functional prerequisite was found for the core idea.
Older stable trees before `dropreason-core.h` will need a small backport
adjustment for the new drop reason, or can use an existing generic
reason.

Phase 4: Mailing List And External Research

Record 4.1: `b4 dig -c 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac` found
`[PATCH net v5]` at the provided lore/patch.msgid link.

Record 4.2: `b4 dig -a` found v1 through v5. v1 added a sysctl and was
NAKed by Justin Iurman; v4 switched to a hard-coded limit; v5 reduced
the limit from 32 to 12.

Record 4.3: No `Reported-by` or bug-report link exists. Web/lore stable
search did not find a stable-specific request or objection.

Record 4.4: Related series context: review discussion referenced IETF
extension-header occurrence work; v5 was the latest and accepted
version.

Record 4.5: No stable mailing-list-specific discussion found. WebFetch
to lore was blocked/timed out, but `b4` successfully retrieved the
thread.

Phase 5: Code Semantic Analysis

Record 5.1: Key functions are `ipv6_skip_exthdr()`, `ipv6_find_hdr()`,
`ip6_protocol_deliver_rcu()`, `ip6_tnl_parse_tlv_enc_lim()`.

Record 5.2: `git grep` found many callers of `ipv6_skip_exthdr()` across
netfilter, XFRM/ESP, drivers, audit/security hooks, ICMPv6, and tunnel
code. `ipv6_find_hdr()` is used by netfilter/nftables, BPF, OVS, IPVS,
SRv6, drivers, and TC. `ip6_protocol_deliver_rcu()` is called from IPv6
input and UDP encapsulation resubmission. `ip6_tnl_parse_tlv_enc_lim()`
is called from GRE/tunnel paths.

Record 5.3: Key callees are `skb_header_pointer()`, `pskb_pull()`,
`pskb_may_pull()`, `raw6_local_deliver()`, `inet6_protos[]` dispatch,
and protocol handlers.

Record 5.4: Reachability is verified from IPv6 receive paths:
`ip6_input_finish()` calls `ip6_protocol_deliver_rcu()`, and
`icmpv6_notify()` calls `ipv6_skip_exthdr()` on quoted inner packets.
These are network packet processing paths.

Record 5.5: Similar prior pattern exists in `47d3d7ac656a` for TLV
count/length limits and in `076b8cad77aa9` for tunnel TLV scanning.

Phase 6: Stable Tree Analysis

Record 6.1: The four key functions exist in checked tags `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v6.19`. Thus the affected code
shape exists across active LTS/stable ranges.

Record 6.2: Expected backport difficulty: clean or minor for newer
trees; minor rework for pre-`dropreason-core.h` trees because
`include/net/dropreason-core.h` is absent in `v5.10`, `v5.15`, and
`v6.1`.

Record 6.3: No alternate stable-specific fix for this exact extension-
header traversal count was found. Related TLV-limiting commits address
adjacent, not identical, loops.

Phase 7: Subsystem Context

Record 7.1: Subsystem is IPv6 networking, criticality IMPORTANT to CORE
for IPv6-enabled systems because packet receive, ICMPv6, netfilter,
tunnel, and driver offload paths call these helpers.

Record 7.2: Subsystem is active; recent history shows multiple
IPv6/tunnel/drop-reason changes, but the unbounded parsing loops
themselves are longstanding.

Phase 8: Impact And Risk

Record 8.1: Affected users are IPv6-enabled systems, especially systems
exposed to crafted IPv6 traffic or using IPv6 tunnels/netfilter paths.

Record 8.2: Trigger is a crafted IPv6 packet chain with many small
extension headers, especially costly when parsed from
fragmented/reassembled skb data. Network reachability depends on
filtering and IPv6 deployment.

Record 8.3: Failure mode is CPU work amplification/DoS risk, not crash
or corruption. Severity: HIGH for exposed IPv6 hosts because it is
remote packet-triggered parser amplification; not CRITICAL because no
verified panic, data loss, or privilege escalation was found.

Record 8.4: Benefit is high: caps an attacker-controlled loop in common
networking code. Risk is low-to-medium: packets with more than 12
traversed extension headers may now be rejected, but reviewers
explicitly judged 12 conservative relative to RFC/IETF occurrence
expectations.

Phase 9: Final Synthesis

Record 9.1: Evidence for backporting: small 25-line fix; real attacker-
controlled parser amplification; network receive reachability verified;
reviewed by networking experts; v1 concerns were resolved; no new UAPI.
Evidence against: behavior change for extreme extension-header chains;
older trees need minor drop-reason backport adjustment; no syzbot/user
report/CVE. Unresolved: no benchmark for this exact v5 patch was found,
and no stable-specific discussion was found.

Record 9.2: Stable rules: obviously correct and reviewed, yes; fixes a
real bug, yes; important issue, yes as network DoS/performance
amplification; small and contained, yes; no new feature/API, yes; stable
apply, likely clean for newer trees and minor adjustment for older
trees.

Record 9.3: No automatic exception category applies. This is not a
device ID, quirk, DT, build, or documentation fix.

Record 9.4: The risk-benefit balance favors backporting.

## Verification
- [Phase 1] Parsed `git show 3744b0964d5267c0b651bcd8f8c25db6bf4ccbac`:
  verified subject, tags, message, and 25-line diff.
- [Phase 2] Read local code in `net/ipv6/exthdrs_core.c`,
  `net/ipv6/ip6_input.c`, `net/ipv6/ip6_tunnel.c`, and
  `include/net/ipv6.h`: verified loops were unbounded before the patch.
- [Phase 3] Ran `git blame` on changed regions: verified long-lived code
  and relevant commit ancestry.
- [Phase 3] Inspected `47d3d7ac656a` and `076b8cad77aa9`: verified
  similar prior DoS-limit work.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, `b4 dig -w`, and `b4 mbox`:
  verified v1-v5 history, reviewers, NAK of sysctl approach, and v5
  acceptance.
- [Phase 5] Ran caller searches for all four functions: verified broad
  IPv6/netfilter/tunnel/driver call surface.
- [Phase 6] Checked `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`:
  verified the affected functions exist; verified `dropreason-core.h` is
  absent before v6.6.
- [Phase 8] Verified reachable call paths in `icmpv6_notify()`,
  `ip6_input_finish()`, `udpv6_queue_rcv_skb()`, and `ip6_gre` tunnel
  code.
- UNVERIFIED: exact exploitability impact across real networks and exact
  CPU-cost benchmark for this specific v5 patch.
- UNVERIFIED: clean application to every currently maintained stable
  branch; older trees likely need minor drop-reason context adjustment.

**YES**

 include/net/dropreason-core.h | 6 ++++++
 include/net/ipv6.h            | 3 +++
 net/ipv6/exthdrs_core.c       | 7 +++++++
 net/ipv6/ip6_input.c          | 5 +++++
 net/ipv6/ip6_tunnel.c         | 4 ++++
 5 files changed, 25 insertions(+)

diff --git a/include/net/dropreason-core.h b/include/net/dropreason-core.h
index a7b7abd66e215..0b674a02665ab 100644
--- a/include/net/dropreason-core.h
+++ b/include/net/dropreason-core.h
@@ -102,6 +102,7 @@
 	FN(FRAG_TOO_FAR)		\
 	FN(TCP_MINTTL)			\
 	FN(IPV6_BAD_EXTHDR)		\
+	FN(IPV6_TOO_MANY_EXTHDRS)	\
 	FN(IPV6_NDISC_FRAG)		\
 	FN(IPV6_NDISC_HOP_LIMIT)	\
 	FN(IPV6_NDISC_BAD_CODE)		\
@@ -513,6 +514,11 @@ enum skb_drop_reason {
 	SKB_DROP_REASON_TCP_MINTTL,
 	/** @SKB_DROP_REASON_IPV6_BAD_EXTHDR: Bad IPv6 extension header. */
 	SKB_DROP_REASON_IPV6_BAD_EXTHDR,
+	/**
+	 * @SKB_DROP_REASON_IPV6_TOO_MANY_EXTHDRS: Number of IPv6 extension
+	 * headers in the packet exceeds IP6_MAX_EXT_HDRS_CNT.
+	 */
+	SKB_DROP_REASON_IPV6_TOO_MANY_EXTHDRS,
 	/** @SKB_DROP_REASON_IPV6_NDISC_FRAG: invalid frag (suppress_frag_ndisc). */
 	SKB_DROP_REASON_IPV6_NDISC_FRAG,
 	/** @SKB_DROP_REASON_IPV6_NDISC_HOP_LIMIT: invalid hop limit. */
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 53c5056508be5..ec95c11b8e434 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -90,6 +90,9 @@ struct ip_tunnel_info;
 #define IP6_DEFAULT_MAX_DST_OPTS_LEN	 INT_MAX /* No limit */
 #define IP6_DEFAULT_MAX_HBH_OPTS_LEN	 INT_MAX /* No limit */
 
+/* Hard limit on traversed IPv6 extension headers */
+#define IP6_MAX_EXT_HDRS_CNT		 12
+
 /*
  *	Addr type
  *	
diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c
index 49e31e4ae7b7f..9d06d487e8b10 100644
--- a/net/ipv6/exthdrs_core.c
+++ b/net/ipv6/exthdrs_core.c
@@ -73,6 +73,7 @@ int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,
 		     __be16 *frag_offp)
 {
 	u8 nexthdr = *nexthdrp;
+	int exthdr_cnt = 0;
 
 	*frag_offp = 0;
 
@@ -82,6 +83,8 @@ int ipv6_skip_exthdr(const struct sk_buff *skb, int start, u8 *nexthdrp,
 
 		if (nexthdr == NEXTHDR_NONE)
 			return -1;
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			return -1;
 		hp = skb_header_pointer(skb, start, sizeof(_hdr), &_hdr);
 		if (!hp)
 			return -1;
@@ -190,6 +193,7 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
 {
 	unsigned int start = skb_network_offset(skb) + sizeof(struct ipv6hdr);
 	u8 nexthdr = ipv6_hdr(skb)->nexthdr;
+	int exthdr_cnt = 0;
 	bool found;
 
 	if (fragoff)
@@ -216,6 +220,9 @@ int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
 			return -ENOENT;
 		}
 
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			return -EBADMSG;
+
 		hp = skb_header_pointer(skb, start, sizeof(_hdr), &_hdr);
 		if (!hp)
 			return -EBADMSG;
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 2bcb981c91aa8..bbad1d4e6b854 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -363,6 +363,7 @@ INDIRECT_CALLABLE_DECLARE(int tcp_v6_rcv(struct sk_buff *));
 void ip6_protocol_deliver_rcu(struct net *net, struct sk_buff *skb, int nexthdr,
 			      bool have_final)
 {
+	int exthdr_cnt = IP6CB(skb)->flags & IP6SKB_HOPBYHOP ? 1 : 0;
 	const struct inet6_protocol *ipprot;
 	struct inet6_dev *idev;
 	unsigned int nhoff;
@@ -447,6 +448,10 @@ void ip6_protocol_deliver_rcu(struct net *net, struct sk_buff *skb, int nexthdr,
 				nexthdr = ret;
 				goto resubmit_final;
 			} else {
+				if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT)) {
+					SKB_DR_SET(reason, IPV6_TOO_MANY_EXTHDRS);
+					goto discard;
+				}
 				goto resubmit;
 			}
 		} else if (ret == 0) {
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0b53488a92290..c1ca9b2806359 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -400,11 +400,15 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw)
 	unsigned int nhoff = raw - skb->data;
 	unsigned int off = nhoff + sizeof(*ipv6h);
 	u8 nexthdr = ipv6h->nexthdr;
+	int exthdr_cnt = 0;
 
 	while (ipv6_ext_hdr(nexthdr) && nexthdr != NEXTHDR_NONE) {
 		struct ipv6_opt_hdr *hdr;
 		u16 optlen;
 
+		if (unlikely(exthdr_cnt++ >= IP6_MAX_EXT_HDRS_CNT))
+			break;
+
 		if (!pskb_may_pull(skb, off + sizeof(*hdr)))
 			break;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] net: usb: cdc_ncm: add Apple Mac USB-C direct networking quirk

[Sasha Levin]

From: Alex Cheema <alex@exolabs.net>

[ Upstream commit a5148bc2fa27092862ac4b9e7b5c8340d60cff34 ]

Apple Silicon Macs expose two CDC NCM "private" data interfaces over
USB-C with VID:PID 0x05ac:0x1905 and product string "Mac". This is the
same protocol Apple already ships on iPhone (0x05ac:0x12a8) and iPad
(0x05ac:0x12ab) for RemoteXPC since iOS 17 -- both data interfaces lack
an interrupt status endpoint, so they rely on the FLAG_LINK_INTR-
conditional bind path introduced in commit 3ec8d7572a69 ("CDC-NCM: add
support for Apple's private interface").

The id_table currently has entries for iPhone and iPad but not for the
Mac. Without a match, cdc_ncm falls through to the generic CDC NCM
class-match entry, which uses the FLAG_LINK_INTR-having cdc_ncm_info
struct, so bind_common() fails on the missing status endpoint and no
netdev appears.

Add id_table entries for both interface numbers (0 and 2) of the Mac,
bound to the existing apple_private_interface_info driver_info.

Verified empirically on a Mac Studio M3 Ultra running macOS 26.5: when
a Mac is connected via USB-C, ioreg shows VID 0x05ac, PID 0x1905,
product string "Mac", with two NCM data interfaces at numbers 0 and 2.
The same PID is presented by all current Apple Silicon Mac models
(MacBook Pro/Air, Mac mini, Mac Studio across the M-series), mirroring
Apple's single-PID-per-family pattern from iPhone/iPad.

After this patch, plugging a Mac into a Linux host running the patched
kernel produces two enx... interfaces (one per data interface),
"ip -br link" lists them as UP, and standard userspace networking
(DHCP, NetworkManager shared mode, etc.) works without any modprobe
overrides or out-of-tree modules.

Signed-off-by: Alex Cheema <alex@exolabs.net>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260429175739.34426-1-alex@exolabs.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: Subsystem is `net: usb: cdc_ncm`; action verb is `add`; intent
is to add an Apple Mac USB-C direct networking quirk/device match.

Record: Tags verified from `git show a5148bc2fa27` and `b4`:
`Signed-off-by: Alex Cheema <alex@exolabs.net>`, `Reviewed-by: Simon
Horman <horms@kernel.org>`, `Link:
https://patch.msgid.link/20260429175739.34426-1-alex@exolabs.net`,
`Signed-off-by: Jakub Kicinski <kuba@kernel.org>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, or `Cc: stable@vger.kernel.org`.

Record: The body describes a real functional failure: Apple Silicon Macs
with VID:PID `05ac:1905` expose private CDC NCM interfaces without
interrupt status endpoints. Without specific IDs, they match the generic
CDC NCM entry, use `cdc_ncm_info` with `FLAG_LINK_INTR`, fail endpoint
collection in `cdc_ncm_bind_common()`, and no netdev appears. The author
reports empirical testing on Mac Studio M3 Ultra.

Record: This is not a hidden memory-safety bug; it is an explicit
hardware ID/quirk fix for already-supported Apple private CDC NCM
handling.

### Phase 2: Diff Analysis
Record: One file changed: `drivers/net/usb/cdc_ncm.c`, 8 insertions, 0
deletions. No functions modified; only `cdc_devs[]` gets two entries.
Scope is single-file, surgical, device-ID style.

Record: Before: Mac interfaces could fall through to the generic CDC NCM
class entry using `cdc_ncm_info`. After: interface numbers `0` and `2`
for `05ac:1905` bind to existing `apple_private_interface_info`.

Record: Bug category is hardware quirk/device ID addition. The local
code verifies `apple_private_interface_info` omits `FLAG_LINK_INTR`,
while `cdc_ncm_info` includes it, and `cdc_ncm_bind_common()` rejects
devices with no status endpoint when `FLAG_LINK_INTR` is set.

Record: Fix quality is high: two exact USB interface-number matches,
reused existing driver_info, no new code path beyond selecting an
existing quirk. Regression risk is very low and limited to Apple VID:PID
`05ac:1905` interfaces `0` and `2`.

### Phase 3: Git History
Record: `git blame` shows `apple_private_interface_info` and the
iPhone/iPad Apple table entries were introduced by `3ec8d7572a69` in
2024.

Record: No `Fixes:` tag is present, but the commit body references
`3ec8d7572a69`; `git show` confirms that commit introduced Apple private
support and the conditional missing-status-endpoint handling.

Record: Recent `cdc_ncm.c` history shows unrelated
bounds/filtering/refactor changes; no prerequisite besides the
referenced Apple private support was found.

Record: `git log --author="Alex Cheema" -10 -- drivers/net/usb` found no
prior local subsystem commits by the author. The patch was reviewed by
Simon Horman and committed by Jakub Kicinski.

Record: Dependency found: stable trees must already contain
`3ec8d7572a69` or an equivalent `apple_private_interface_info`; older
trees without that support will not take this patch standalone.

### Phase 4: Mailing List And External Research
Record: `b4 dig -c a5148bc2fa27` found the original submission at the
patch.msgid.link URL.

Record: `b4 dig -c a5148bc2fa27 -a` found only v1; no later revision.

Record: `b4 dig -c a5148bc2fa27 -w` showed the right net/USB maintainers
and lists were included, including Oliver Neukum, Bjørn Mork, Jakub
Kicinski, netdev, and linux-usb.

Record: Full thread via `b4 mbox` had three messages: the patch, Simon
Horman’s `Reviewed-by`, and patchwork-bot saying Jakub applied it to
`netdev/net.git` as `a5148bc2fa27`. No NAKs or concerns observed.

Record: WebFetch of lore/stable was blocked by Anubis, so stable-
specific web discussion could not be independently checked. No stable
nomination appeared in the fetched thread.

### Phase 5: Code Semantic Analysis
Record: Modified object is `cdc_devs[]`; no function body changed.

Record: Call/reachability path verified: `cdc_ncm_driver.id_table =
cdc_devs`, `.probe = usbnet_probe`; `usbnet_probe()` reads
`prod->driver_info`, sets `dev->driver_info`, then calls `info->bind`,
which is `cdc_ncm_bind()`, which calls `cdc_ncm_bind_common()`.

Record: Key callees are endpoint discovery and bind setup in
`cdc_ncm_bind_common()`, especially the verified endpoint check
requiring status only when `FLAG_LINK_INTR` is set.

Record: User reachability is USB device enumeration/probe when an
affected Mac is connected to a Linux host. This is not syscall-triggered
by an unprivileged local user; it is hardware-triggered.

Record: Similar pattern found: existing iPhone/iPad Apple entries
already bind private interfaces to `apple_private_interface_info`.

### Phase 6: Stable Tree Analysis
Record: `git merge-base --is-ancestor 3ec8d7572a69 <tag>` verified
`3ec8d7572a69` is absent from `v5.15`, `v6.1`, `v6.6`, `v6.9`, and
`v6.10`, but present in `v6.11`, `v6.12`, and `v7.0`.

Record: `git show <tag>:drivers/net/usb/cdc_ncm.c | rg ...` verified
`v6.11+` have `apple_private_interface_info` and iPhone/iPad Apple
entries, but not the Mac `0x1905` entries.

Record: `git apply --check` succeeded against the current `7.0.5` tree.
Backport should be clean for trees with the same Apple-private support;
older trees need the prerequisite and are not standalone targets.

Record: No alternate related stable fix was found locally.

### Phase 7: Subsystem Context
Record: Subsystem is USB networking driver code, under
`drivers/net/usb`. Criticality is important for users of this hardware,
not core/universal.

Record: `scripts/get_maintainer.pl -f drivers/net/usb/cdc_ncm.c`
confirmed the patch was sent to the relevant USB CDC Ethernet and
networking maintainers/lists. Recent `drivers/net/usb` history shows
active maintenance.

### Phase 8: Impact And Risk
Record: Affected users are Linux hosts connecting to Apple Silicon Macs
via USB-C direct CDC NCM networking.

Record: Trigger is plugging in the matching Mac USB device. The failure
is likely whenever the unsupported `05ac:1905` private interfaces are
exposed and lack the interrupt status endpoint, based on the commit body
and verified bind logic.

Record: Failure mode is functional loss: no netdev appears. Severity is
medium by generic bug severity, but it fits the stable exception for new
device IDs/hardware quirks.

Record: Benefit is high for affected hardware users: direct networking
works without overrides/out-of-tree modules. Risk is very low: two
exact-match USB ID entries selecting existing behavior.

### Phase 9: Final Synthesis
Evidence for backporting: it is a classic stable-acceptable hardware
quirk/device ID addition; it fixes a verified bind failure mechanism; it
is tiny and contained; it reuses existing Apple private CDC NCM support;
it was reviewed and applied by netdev maintainership; it applies cleanly
to the current stable-style tree.

Evidence against backporting: it is not a crash/security/data-corruption
fix, and it is not standalone for stable trees older than `v6.11` unless
`3ec8d7572a69` is also present.

Stable rules checklist:
1. Obviously correct and tested: yes; exact ID entries, author-tested,
   reviewer accepted.
2. Fixes a real bug: yes; no netdev appears for matching hardware.
3. Important issue: yes under hardware support/quirk exception, though
   not critical severity.
4. Small and contained: yes, 8 insertions in one table.
5. No new APIs/features: yes, no API or new driver; only IDs for
   existing behavior.
6. Applies to stable: yes for trees with Apple private support; older
   trees need prerequisite handling.

Exception category: new USB device ID / hardware quirk for an existing
driver path.

## Verification
- [Phase 1] Parsed `git show a5148bc2fa27`: confirmed subject, body,
  trailers, reviewed-by, link, and maintainer signoff.
- [Phase 2] Read `drivers/net/usb/cdc_ncm.c`: confirmed `cdc_ncm_info`
  has `FLAG_LINK_INTR`, `apple_private_interface_info` does not, and
  `cdc_ncm_bind_common()` fails missing status endpoints when
  `FLAG_LINK_INTR` is set.
- [Phase 3] `git blame` confirmed Apple private support and existing
  Apple IDs came from `3ec8d7572a69`.
- [Phase 3] `git show 3ec8d7572a69` confirmed it introduced Apple
  private CDC NCM support and the conditional endpoint check.
- [Phase 4] `b4 dig -c a5148bc2fa27`: found the original lore
  submission.
- [Phase 4] `b4 dig -a`: only v1 found.
- [Phase 4] `b4 dig -w`: confirmed relevant maintainers/lists were
  included.
- [Phase 4] `b4 mbox`: confirmed Simon Horman review and patchwork
  application by Jakub Kicinski.
- [Phase 5] `rg` and `ReadFile` traced `cdc_devs[]` to `usbnet_probe()`
  to `cdc_ncm_bind()` to `cdc_ncm_bind_common()`.
- [Phase 6] Tag ancestry checks confirmed prerequisite exists in
  `v6.11+` but not `v6.10` and older checked tags.
- [Phase 6] `git apply --check` confirmed clean apply to current tree.
- UNVERIFIED: Independent confirmation that all current Apple Silicon
  Macs use PID `0x1905`; this is author-stated in the patch, not
  independently verified here.
- UNVERIFIED: Stable mailing-list search via WebFetch was blocked by
  Anubis; no stable-specific discussion was visible in the fetched `b4`
  thread.

This should be backported to stable trees that already contain the Apple
private CDC NCM support, because it is a low-risk hardware ID/quirk fix
that restores networking for real hardware.

**YES**

 drivers/net/usb/cdc_ncm.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index bb9929727eb93..0223a172851ec 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -2012,6 +2012,14 @@ static const struct usb_device_id cdc_devs[] = {
 		.driver_info = (unsigned long)&apple_private_interface_info,
 	},
 
+	/* Mac */
+	{ USB_DEVICE_INTERFACE_NUMBER(0x05ac, 0x1905, 0),
+		.driver_info = (unsigned long)&apple_private_interface_info,
+	},
+	{ USB_DEVICE_INTERFACE_NUMBER(0x05ac, 0x1905, 2),
+		.driver_info = (unsigned long)&apple_private_interface_info,
+	},
+
 	/* Ericsson MBM devices like F5521gw */
 	{ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
 		| USB_DEVICE_ID_MATCH_VENDOR,
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.15] net: usb: r8152: add TRENDnet TUC-ET2G v2.0

[Sasha Levin]

From: Aleksander Jan Bajkowski <olek2@wp.pl>

[ Upstream commit f93836b236773862e9ee268a82e3614caf77ea01 ]

The TRENDnet TUC-ET2G V2.0 is an RTL8156B based 2.5G Ethernet controller.

Add the vendor and product ID values to the driver. This makes Ethernet
work with the adapter.

Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Birger Koblitz <mail@birger-koblitz.de>
Link: https://patch.msgid.link/20260430213435.21821-1-olek2@wp.pl
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `net: usb: r8152`; action verb `add`; claimed
intent: add TRENDnet TUC-ET2G v2.0 USB device ID so the existing `r8152`
driver binds to the adapter.

Step 1.2 Record: Tags present:
- `Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>`
- `Reviewed-by: Andrew Lunn <andrew@lunn.ch>`
- `Reviewed-by: Birger Koblitz <mail@birger-koblitz.de>`
- `Link: https://patch.msgid.link/20260430213435.21821-1-olek2@wp.pl`
- `Signed-off-by: Jakub Kicinski <kuba@kernel.org>`

No `Fixes:`, `Reported-by:`, `Tested-by:`, or `Cc:
stable@vger.kernel.org` tag was present. Absence of those tags is not a
negative signal here.

Step 1.3 Record: The body describes a real hardware support failure:
TRENDnet TUC-ET2G V2.0 is RTL8156B-based, but without its USB
vendor/product ID in `rtl8152_table`, Ethernet does not work with that
adapter. No affected kernel versions are named.

Step 1.4 Record: This is not a hidden memory/synchronization bug. It is
an explicit new USB device ID addition to an existing driver, which is a
stable exception category.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `drivers/net/usb/r8152.c`, `+1/-0`.
No function body changed. The modified object is `rtl8152_table`. Scope:
single-file surgical device-ID addition.

Step 2.2 Record: Before the change, the table contained TRENDnet
`0xe02b` but not `0xe02c`, so USB matching would not select `r8152` for
`20f4:e02c`. After the change, `USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c)`
is matched by the driver table used by both `rtl8152_driver.id_table`
and `rtl8152_cfgselector_driver.id_table`.

Step 2.3 Record: Bug category is hardware enablement / USB device ID
addition. It does not touch error paths, locking, reference counts,
memory safety, or public APIs.

Step 2.4 Record: The fix is obviously correct if the ID maps to RTL8156B
hardware. I verified the device identity externally: WikiDevi lists TUC-
ET2G v2.0R as USB ID `20f4:e02c` with Realtek RTL8156B, and TRENDnet’s
own support page confirms the TUC-ET2G v2 product. Regression risk is
very low; existing devices are unaffected unless another incompatible
device uses the same exact USB ID.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` around the table showed the existing
TRENDnet `0xe02b` entry came from `15fba71533bc` and the new `0xe02c`
line comes from `f93836b23677`. The table terminator dates back to
`ac718b69301c`. The “bug” is not introduced by a code commit; it is the
absence of a product-specific ID for existing supported silicon.

Step 3.2 Record: No `Fixes:` tag, so there is no introducing commit to
follow.

Step 3.3 Record: Recent related history includes `15fba71533bc` adding
the first TRENDnet TUC-ET2G ID and `dc9c67820f81` adding a TP-Link ID.
The candidate is standalone on trees that already have
`VENDOR_ID_TRENDNET`.

Step 3.4 Record: The author has at least one prior `r8152` device-ID
commit, `848b09d53d92` for Dell Alienware AW1022z. The patch was
reviewed by Andrew Lunn and Birger Koblitz and applied by Jakub
Kicinski.

Step 3.5 Record: Dependency found: `VENDOR_ID_TRENDNET` was introduced
by `15fba71533bc`, and `git merge-base --is-ancestor` confirms that
commit is an ancestor of `f93836b23677`. Mainline release tags `v5.15`,
`v6.1`, `v6.6`, `v6.12`, and `v6.19` lack `VENDOR_ID_TRENDNET`, while
`v7.0-rc3` has it. Older stable backports therefore need either
`15fba71533bc` first or a small backport adjustment adding `#define
VENDOR_ID_TRENDNET 0x20f4`.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f93836b23677` found the original patch
submission by patch-id. `b4 dig -a` reported the accepted one-patch
submission at `20260430213435.21821-1-olek2@wp.pl`; `b4` also found an
earlier identical submission from
`20260426214909.3426105-1-olek2@wp.pl`. The earlier thread had Andrew
Lunn asking for repost after netdev opened and giving his `Reviewed-by`.
No NAK or technical objection found.

Step 4.2 Record: `b4 dig -w` showed the patch was sent to netdev
maintainers/lists and USB networking lists, including Andrew Lunn, David
Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni, Realtek contacts,
`linux-usb`, `netdev`, and `linux-kernel`. `MAINTAINERS` confirms those
netdev maintainers for `NETWORKING DRIVERS`, and `drivers/net/usb/` is
under `USB NETWORKING DRIVERS`.

Step 4.3 Record: No separate bug report or `Reported-by` tag. External
hardware verification found TUC-ET2G v2.0R as `20f4:e02c` / RTL8156B.

Step 4.4 Record: This is a single-patch submission, not a multi-patch
fix series. The only practical dependency for older trees is the
TRENDnet vendor define from the prior TUC-ET2G ID commit.

Step 4.5 Record: WebFetch to lore was blocked by Anubis. WebSearch did
not find stable-specific discussion for `f93836b23677` or the patch
message ID. No stable objection found.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: No functions modified. Modified data structure:
`rtl8152_table`.

Step 5.2 Record: `rtl8152_table` is referenced by
`MODULE_DEVICE_TABLE(usb, rtl8152_table)`, `rtl8152_driver.id_table`,
and `rtl8152_cfgselector_driver.id_table`. Matching devices enter the
normal USB probe path via `rtl8152_probe`.

Step 5.3 Record: The relevant probe path checks vendor-specific
interface class, `rtl_check_vendor_ok`, `rtl8152_get_version`, then
calls `rtl8152_probe_once`. The config selector uses `__rtl_get_hw_ver`.
This patch adds no new calls.

Step 5.4 Record: Reachability is USB device enumeration: plugging in or
booting with the adapter attached. It is not a remote or syscall-
triggered security issue.

Step 5.5 Record: Similar pattern exists throughout the same table for
Realtek, Lenovo, TP-Link, D-Link, Dell, ASUS, and earlier TRENDnet IDs.
`git log -S'0xe02c'` found no prior `0xe02c` entry in the checked
history.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked mainline release tags `v5.15`, `v6.1`, `v6.6`,
`v6.12`, and `v6.19`: all contain `0x8156` and RTL8156B version
handling, but not the TRENDnet `0xe02c` ID. This means the supported
chipset path exists in those releases, but the product-specific match is
missing.

Step 6.2 Record: Backport difficulty is low. It applies cleanly to trees
with `VENDOR_ID_TRENDNET` / `0xe02b`; older bases need a minor
context/define adjustment or the prior TRENDnet ID patch.

Step 6.3 Record: No alternate local fix for `0xe02c` was found. No
stable-specific replacement fix was verified.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is `drivers/net/usb`, USB Ethernet networking
driver. Criticality: driver-specific, important for users of this
hardware, not core-kernel-wide.

Step 7.2 Record: The file is active, with recent `r8152` feature and fix
commits, but this change is isolated to the USB ID table and does not
depend on recent functional refactoring except the vendor
define/backport context noted above.

## Phase 8: Impact And Risk
Step 8.1 Record: Affected users are systems with TRENDnet TUC-ET2G V2.0
and `CONFIG_USB_RTL8152`.

Step 8.2 Record: Trigger is common for affected users: adapter insertion
or boot with the adapter connected. Not remotely triggerable; physical
USB access is needed.

Step 8.3 Record: Failure mode is device non-binding / Ethernet
unavailable. Severity is not crash/security-critical, but it is a real
user-visible hardware functionality failure.

Step 8.4 Record: Benefit is high for affected stable users because it
makes the adapter work with an already-supported RTL8156B driver. Risk
is very low: one table entry, no behavior change for existing IDs.

## Phase 9: Final Synthesis
Evidence for backporting:
- New USB device ID for existing driver and already-supported RTL8156B
  silicon.
- Fixes a real user-visible failure: Ethernet does not work with this
  adapter.
- One-line, single-file, no API or behavior change for existing
  hardware.
- Reviewed by Andrew Lunn and Birger Koblitz; applied by Jakub Kicinski.
- Hardware identity verified as TRENDnet `20f4:e02c` / RTL8156B.

Evidence against backporting:
- Not a crash, data corruption, security, or deadlock fix.
- Older stable bases may need the prior `VENDOR_ID_TRENDNET` definition
  or a tiny backport adjustment.

Unresolved:
- I did not verify every active stable branch state directly; I verified
  mainline release tags and the dependency relationship. Lore WebFetch
  was blocked, but `b4` successfully fetched the thread.

Stable rules checklist:
1. Obviously correct and tested? Yes, one matching-table entry;
   reviewed; hardware ID verified.
2. Fixes a real bug affecting users? Yes, adapter does not bind/work
   without the ID.
3. Important issue? Yes under the stable “new device IDs” exception,
   though not crash/security.
4. Small and contained? Yes, one insertion in one file.
5. No new features/APIs? Yes, no API or behavioral change except
   matching this USB device.
6. Can apply to stable trees? Yes with low difficulty; older trees may
   need `VENDOR_ID_TRENDNET`.

Exception category: New USB device ID for an existing driver. This is a
standard stable-appropriate exception.

## Verification
- [Phase 1] Parsed commit `f93836b236773862e9ee268a82e3614caf77ea01`
  with `git show`; confirmed subject, body, tags, and `+1/-0` diff.
- [Phase 2] Compared `git diff f938^..f938`; confirmed only `{
  USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c) }` is added.
- [Phase 3] Ran `git blame` around `rtl8152_table`; confirmed existing
  `0xe02b` from `15fba71533bc` and new `0xe02c` from `f93836b23677`.
- [Phase 3] Ran `git merge-base --is-ancestor 15fba71533bc
  f93836b23677`; confirmed the vendor define dependency is in the
  candidate’s ancestry.
- [Phase 3] Checked release tags `v5.15`, `v6.1`, `v6.6`, `v6.12`,
  `v6.19`, `v7.0-rc3`, `v7.1-rc3`; confirmed older release tags have
  RTL8156/RTL_VER_13 support but lack TRENDnet IDs until `v7.0-rc3`.
- [Phase 4] Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; confirmed
  patch-id match, one-patch submission, recipients, and
  review/application thread.
- [Phase 4] Read full `b4 mbox` threads; confirmed Andrew Lunn review on
  repost request, Birger Koblitz review, and patchwork notification that
  Jakub applied it.
- [Phase 4] WebFetch to lore was blocked by Anubis; external GitHub
  commit fetch confirmed the commit metadata and diff.
- [Phase 4] WebFetch of WikiDevi and TRENDnet pages verified TUC-ET2G v2
  hardware identity; WikiDevi specifically listed USB ID `20f4:e02c` and
  RTL8156B.
- [Phase 5] Searched `rtl8152_table` references; confirmed use by
  `MODULE_DEVICE_TABLE`, `rtl8152_driver.id_table`, and
  `rtl8152_cfgselector_driver.id_table`.
- [Phase 5] Read `rtl8152_probe` and config selector code; confirmed
  affected path is USB enumeration/probe, with no changed runtime logic.
- [Phase 7] Checked `MAINTAINERS`; confirmed netdev maintainers and
  `drivers/net/usb/` list coverage.
- [Phase 8] Checked `drivers/net/usb/Kconfig`; confirmed affected
  configuration is `CONFIG_USB_RTL8152`.

This is exactly the kind of low-risk new USB ID addition stable trees
normally take.

**YES**

 drivers/net/usb/r8152.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0c83bbbea2e7c..0ac2b079e435c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -10055,6 +10055,7 @@ static const struct usb_device_id rtl8152_table[] = {
 	{ USB_DEVICE(VENDOR_ID_DELL,    0xb097) },
 	{ USB_DEVICE(VENDOR_ID_ASUS,    0x1976) },
 	{ USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02b) },
+	{ USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c) },
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] wifi: nl80211: require CAP_NET_ADMIN over the target netns in SET_WIPHY_NETNS

[Sasha Levin]

From: Maoyi Xie <maoyi.xie@ntu.edu.sg>

[ Upstream commit 15994bb0cbb8fc4879da7552ddd08c1896261c39 ]

NL80211_CMD_SET_WIPHY_NETNS dispatches with GENL_UNS_ADMIN_PERM, which
verifies that the caller has CAP_NET_ADMIN for the source netns. It
doesn't verify that the caller has CAP_NET_ADMIN over the target netns
selected by NL80211_ATTR_NETNS_FD or NL80211_ATTR_PID.

This diverges from the convention enforced in
net/core/rtnetlink.c::rtnl_get_net_ns_capable():

    /* For now, the caller is required to have CAP_NET_ADMIN in
     * the user namespace owning the target net ns.
     */
    if (!sk_ns_capable(sk, net->user_ns, CAP_NET_ADMIN))
        return ERR_PTR(-EACCES);

A user with CAP_NET_ADMIN in their own user namespace can therefore
push a wiphy into an arbitrary netns (including init_net) over which
they have no privilege.

Mirror the rtnetlink convention by requiring CAP_NET_ADMIN in the
target netns before calling cfg80211_switch_netns().

Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Link: https://patch.msgid.link/20260506064854.2207105-2-maoyixie.tju@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Record: `wifi: nl80211` subsystem; action verb `require`; intent is to
require `CAP_NET_ADMIN` over the target network namespace before
`NL80211_CMD_SET_WIPHY_NETNS` moves a wiphy.

Record: Tags in the provided commit message:
`Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>`, `Link: https://patch.
msgid.link/20260506064854.2207105-2-maoyixie.tju@gmail.com`, `Signed-
off-by: Johannes Berg <johannes.berg@intel.com>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, or `Cc: stable` tag was
present in the provided message.

Record: The described bug is an authorization gap. `GENL_UNS_ADMIN_PERM`
verifies `CAP_NET_ADMIN` for the netlink socket/source netns, but
`NL80211_ATTR_NETNS_FD` / `NL80211_ATTR_PID` selects a target netns that
was not separately checked. The b4-fetched cover letter includes a
concrete reproducer with `mac80211_hwsim`: a caller privileged only in
its own user namespace can move a delegated wiphy back into `init_net`.

Record: This is not a hidden cleanup fix; it is an explicit
security/permission bug fix.

### Phase 2: Diff Analysis
Record: One file changed, `net/wireless/nl80211.c`, with 13 insertions
in `nl80211_wiphy_netns()`. Scope is a single-function surgical fix.

Record: Before: after resolving the target netns and checking
`IS_ERR(net)`, the function directly called `cfg80211_switch_netns()` if
the wiphy was not already in that netns. After: it first checks
`ns_capable(net->user_ns, CAP_NET_ADMIN)`, drops the netns reference
with `put_net(net)`, and returns `-EPERM` on failure.

Record: Bug category is security authorization / logic correctness. The
missing check allowed a source-netns-capable caller to affect a
different target netns without privilege there.

Record: Fix quality is high: small, localized, follows the verified
rtnetlink convention in `rtnl_get_net_ns_capable()`, and preserves
reference cleanup. Regression risk is low and limited to denying
previously accepted unauthorized cross-netns moves.

### Phase 3: Git History Investigation
Record: `git blame` on the current stable checkout blamed the function
body to a repository snapshot-style commit, so it was not useful for
introduction history. `git log v2.6.29..v2.6.32 -S...` found the
command/function introduced by `463d018323851` (`cfg80211: make aware of
net namespaces`), first contained in `v2.6.32-rc1`.

Record: No `Fixes:` tag is present, so there was no tagged commit to
follow.

Record: Recent local `net/wireless/nl80211.c` history showed unrelated
wireless fixes/conversions and no existing equivalent target-netns
capability fix.

Record: No local prior `Maoyi Xie` commits were found under
`net/wireless`. `MAINTAINERS` verifies Johannes Berg as maintainer for
`802.11 (including CFG80211/NL80211)`, and the patch was addressed to
Johannes on linux-wireless.

Record: No code dependency was found for this patch. It is patch 1/2 in
the submitted series; patch 2 is related namespace hardening, but patch
1 is standalone for the direct permission bypass.

### Phase 4: Mailing List And External Research
Record: No commit hash was provided and the exact subject was not found
in local `master`, `wireless-next`, `net-next`, or `fixes-next`, so `b4
dig -c <commit>` was not applicable. I used the provided message-id with
`b4 am`/`b4 mbox`.

Record: `b4 am` found `[PATCH v3 0/2] wifi: nl80211: tighten netns
handling in SET_WIPHY_NETNS and dump continuation`, including this patch
as `v3 1/2`. `b4 am -c` did not report a newer revision. Attempts to
fetch v1/v2 directly with `b4 -v 1/-v 2` did not find those revisions,
but the v3 cover records that patch 1 was unchanged since v1.

Record: The full mbox contained three messages: cover, patch 1, patch 2.
It did not contain reviewer reply messages, but the cover records
Johannes review feedback about trailers/comment wording and says no code
changes since v2.

Record: Original recipients were Johannes Berg, `linux-
wireless@vger.kernel.org`, and `linux-kernel@vger.kernel.org`. No stable
nomination or NAK was found in the fetched mbox. Lore WebFetch searches
were blocked by Anubis, so stable-list discussion could not be
independently verified through WebFetch.

### Phase 5: Code Semantic Analysis
Record: Modified function: `nl80211_wiphy_netns()`.

Record: Caller surface: the only direct reference is the generic-netlink
op for `NL80211_CMD_SET_WIPHY_NETNS`; `genl_family_rcv_msg()` checks
`GENL_UNS_ADMIN_PERM` against `net->user_ns`, then
`genl_family_rcv_msg_doit()` calls `ops->doit()`, reaching
`nl80211_wiphy_netns()` from userspace netlink.

Record: Key callees: `get_net_ns_by_pid()`, `get_net_ns_by_fd()`, new
`ns_capable(net->user_ns, CAP_NET_ADMIN)`, `cfg80211_switch_netns()`,
and `put_net()`. `cfg80211_switch_netns()` moves associated wireless
netdevs with `dev_change_net_namespace()` and updates `wiphy_net_set()`.

Record: Reachability is verified by the op table and by the b4 cover’s
PoC. A userspace caller can trigger the path by sending
`NL80211_CMD_SET_WIPHY_NETNS` with target PID or netns fd.

Record: Similar convention verified in `rtnl_get_net_ns_capable()`,
which checks target `net->user_ns` before using another netns.

### Phase 6: Stable Tree Analysis
Record: The vulnerable handler/op shape exists in `v5.4`, `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.19`, and current `7.0.y`, with no
`ns_capable(net->user_ns, CAP_NET_ADMIN)` check in the handler.

Record: `v3.18` has `NL80211_CMD_SET_WIPHY_NETNS`, but uses
`GENL_ADMIN_PERM`, so the unprivileged-user-namespace aspect is not the
same there. For active modern stable trees, the issue is present.

Record: `git apply --check` of the fetched v3 mbox succeeds on the
current `7.0.y` checkout. Older stable trees have line offsets and minor
surrounding differences, but the same local hunk context exists at least
in `v5.4`; expected backport difficulty is clean or minor-context-only.

Record: No related local fix already present was found by subject/grep
searches.

### Phase 7: Subsystem Context
Record: Subsystem is cfg80211/nl80211 wireless configuration.
Criticality is IMPORTANT: it is not core-mm/VFS, but it is a userspace-
facing network configuration and permission boundary.

Record: The wireless subsystem is active in local history, with recent
cfg80211/nl80211-adjacent fixes.

### Phase 8: Impact And Risk
Record: Affected users are systems with cfg80211/nl80211, network
namespaces/user namespaces, and a `WIPHY_FLAG_NETNS_OK` wiphy. Verified
examples include `mac80211` and drivers setting the flag such as
`brcmfmac`, `mwifiex`, and `qtnfmac`.

Record: Trigger requires the caller to hold a movable wiphy in its own
netns and pass a target netns fd or pid. The b4 cover verifies this is
reachable from an unprivileged user namespace after legitimate admin
delegation using `mac80211_hwsim`.

Record: Failure mode is a security/namespace isolation violation:
unauthorized movement of a wiphy into a netns, including `init_net`,
where the caller lacks privilege. Severity is HIGH because it bypasses
kernel namespace permission boundaries.

Record: Benefit is high for stable users because it closes a concrete
privilege boundary bug. Risk is low: 13 lines, one function, no new API,
no data structure change, and only unauthorized operations change
behavior.

### Phase 9: Final Synthesis
Record: Evidence for backporting: real security/authorization bug,
concrete PoC in the submitted cover, reachable userspace netlink
command, vulnerable code present across modern stable trees, small
contained fix, and it mirrors an existing rtnetlink convention.

Record: Evidence against backporting: no `Fixes:`/stable tag, no fetched
reviewer reply carrying an explicit stable nomination, and the exact
applied commit hash was not present in local searched branches. These do
not outweigh the verified technical issue.

Record: Unresolved: I could not verify the final applied commit object
or run `b4 dig -c` because no commit hash was provided and local branch
searches did not find the subject. WebFetch to lore/stable was blocked
by Anubis. I did not run the runtime PoC or a kernel build.

Stable rules checklist:
1. Obviously correct and tested: yes by inspection; PoC result described
   in b4 cover, though not locally rerun.
2. Fixes a real bug affecting users: yes, verified missing target-netns
   authorization.
3. Important issue: yes, security/namespace permission bypass.
4. Small and contained: yes, one function, 13 added lines.
5. No new features or APIs: yes.
6. Can apply to stable: yes for current `7.0.y`; older active stable
   trees likely clean/minor context based on matching code.

Exception category: none. This is not a device ID/quirk/build/doc fix;
it is a security permission fix.

## Verification
- [Phase 1] Parsed provided subject/tags and b4-fetched patch/cover;
  found no `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, or
  stable tag.
- [Phase 2] Compared provided diff and b4 mbox patch; confirmed 13 lines
  added to `nl80211_wiphy_netns()`.
- [Phase 3] `git blame -L` was not useful due snapshot-style history;
  `git log v2.6.29..v2.6.32 -S...` found `463d018323851`, first
  contained in `v2.6.32-rc1`.
- [Phase 3] `git log --author='Maoyi Xie' -- net/wireless` found no
  local prior commits.
- [Phase 3] `MAINTAINERS` confirms Johannes Berg maintains `802.11
  (including CFG80211/NL80211)`.
- [Phase 4] `b4 am` found v3 2-patch series and the supplied patch
  message-id.
- [Phase 4] `b4 am -c` found no newer revision.
- [Phase 4] `b4 mbox` saved the full 3-message thread; no stable
  nomination or NAK was present there.
- [Phase 5] `rg` confirmed `nl80211_wiphy_netns()` is reached via the
  `NL80211_CMD_SET_WIPHY_NETNS` generic-netlink op.
- [Phase 5] Read `genetlink.c`; confirmed `GENL_UNS_ADMIN_PERM` checks
  `net->user_ns` before calling `ops->doit()`.
- [Phase 5] Read `cfg80211_switch_netns()`; confirmed it moves wireless
  netdevs and changes the wiphy netns.
- [Phase 6] Checked `v5.4`, `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
  `v6.19`, and current `7.0.y`; all have the handler/op without the
  target `ns_capable()` check.
- [Phase 6] `git apply --check` of the b4 mbox succeeded on current
  `7.0.y`.
- [Phase 8] `rg WIPHY_FLAG_NETNS_OK` verified affected mac80211 and
  several wireless drivers expose movable wiphys.
- UNVERIFIED: exact final commit SHA and final applied-object metadata,
  because the subject was not found in local searched branches.
- UNVERIFIED: stable-list discussion via WebFetch, because lore WebFetch
  returned Anubis anti-bot pages.
- UNVERIFIED: local runtime PoC/build; not performed.

This should be backported to stable kernel trees that contain the
`GENL_UNS_ADMIN_PERM` version of `NL80211_CMD_SET_WIPHY_NETNS`,
especially active v5.4+ stable/LTS trees.

**YES**

 net/wireless/nl80211.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ce3121b1c3319..13c2943ad3e4b 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -13568,6 +13568,19 @@ static int nl80211_wiphy_netns(struct sk_buff *skb, struct genl_info *info)
 	if (IS_ERR(net))
 		return PTR_ERR(net);
 
+	/*
+	 * The caller already has CAP_NET_ADMIN over the source netns
+	 * (enforced by GENL_UNS_ADMIN_PERM on the genl op). Mirror the
+	 * convention used by net/core/rtnetlink.c::rtnl_get_net_ns_capable()
+	 * and require CAP_NET_ADMIN over the target netns as well, so that
+	 * a caller that is privileged in their own user namespace cannot
+	 * push a wiphy into a netns where they have no privilege.
+	 */
+	if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+		put_net(net);
+		return -EPERM;
+	}
+
 	err = 0;
 
 	/* check if anything to do */
-- 
2.53.0