[PATCH AUTOSEL 7.0-5.15] net: usb: r8152: add TRENDnet TUC-ET2G v2.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-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-6.18] tools/ynl: add missing uapi header deps in Makefile.deps

[Sasha Levin]

From: Stanislav Fomichev <sdf.kernel@gmail.com>

[ Upstream commit 46e9b0224475abc739612ef72c35b7c90211a0c1 ]

ethtool.h includes linux/typelimits.h which is a relatively new header
not yet shipped in most distro kernel-header packages. Without the
explicit entry, the build silently falls through to -idirafter.

dev_energymodel.h is a new YNL family whose uapi header is not in
system paths at all and was missing a CFLAGS entry entirely.

Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260508204114.205896-2-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit
`46e9b0224475` `tools/ynl: add missing uapi header deps in
Makefile.deps`

## Phase Walkthrough
### Phase 1: Commit Message Forensics
Record 1.1: Subsystem `tools/ynl`; action verb `add`; intent is to add
missing YNL uAPI header dependency entries.

Record 1.2: Tags present: `Signed-off-by: Stanislav Fomichev
<sdf@fomichev.me>`, `Link:
https://patch.msgid.link/20260508204114.205896-2-sdf@fomichev.me`,
`Signed-off-by: Jakub Kicinski <kuba@kernel.org>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by`, `Cc: stable`.

Record 1.3: The described problem is incomplete `Makefile.deps`:
`ethtool.h` includes the newer `linux/typelimits.h`, and
`dev_energymodel.h` has a YNL family/spec but no `CFLAGS_dev-
energymodel` entry. Symptom is YNL tools/header dependency build
correctness with distro kernel headers; no crash/security/data-
corruption symptom is described.

Record 1.4: This is a build/tooling correctness fix, not a hidden
runtime bug fix.

### Phase 2: Diff Analysis
Record 2.1: One file changed: `tools/net/ynl/Makefile.deps`, `+3/-1`. No
functions; Makefile variables only. Scope is single-file surgical.

Record 2.2: Before: `ethtool` force-included `ethtool.h`,
`ethtool_netlink.h`, and generated ethtool netlink headers, but not
`typelimits.h`; `dev-energymodel` had no per-family CFLAGS. After:
`typelimits.h` is explicitly force-included before `ethtool.h`, and
`CFLAGS_dev-energymodel` force-includes `dev_energymodel.h`.

Record 2.3: Bug category is build/tooling dependency correctness. It is
not memory safety, locking, refcounting, or runtime logic.

Record 2.4: Fix quality is high: tiny, declarative Makefile-only change.
Regression risk is low for `v7.0.y`; but not suitable unmodified for
older trees lacking `include/uapi/linux/typelimits.h`.

### Phase 3: Git History
Record 3.1: Blame showed the affected `CFLAGS_ethtool` line came from
`46fb3ba95b93`, later ethtool deps from `0bdcfaf84a942`; `get_hdr_inc2`
came from `db6b35cffe59`.

Record 3.2: No `Fixes:` tag, so no target commit to follow.

Record 3.3: Related history includes prior YNL old-header/build fixes:
`db6b35cffe59 tools: ynl: fix build on systems with old kernel headers`,
`0bdcfaf84a942 tools: ynl: add all headers to makefile deps`, and
several YNL family additions.

Record 3.4: Author Stanislav Fomichev has related net/YNL commits; Jakub
Kicinski committed it and is a netdev maintainer.

Record 3.5: Dependency check: `dev_energymodel.h` and `dev-
energymodel.yaml` exist in `v6.19+`; `typelimits.h` and the ethtool
include of it exist in `v7.0+`. The full patch is therefore appropriate
as-is for `v7.0.y`, not for `v6.19.y`.

### Phase 4: Mailing List
Record 4.1: `b4 dig` found the original submission at the provided patch
link. It was `[PATCH net-next 1/2]`.

Record 4.2: `b4 dig -w` showed netdev maintainers/lists were included:
`netdev`, `davem`, `edumazet`, `kuba`, `pabeni`, Donald Hunter, Simon
Horman, and `linux-kernel`.

Record 4.3: No separate bug report, syzbot report, or user crash report
was found. WebFetch of the patch URL was blocked by Anubis, but `b4`
retrieved the lore thread.

Record 4.4: It was part of a 2-patch series. Patch 1 was applied to
`netdev/net.git`; patch 2, the check-deps target, was not applied.
Jakub’s concern was about patch 2 being better as a NIPA check, not
about patch 1.

Record 4.5: No stable-specific discussion or stable nomination found.

### Phase 5: Code Semantic Analysis
Record 5.1: No C functions modified; key Makefile variables are
`CFLAGS_ethtool` and new `CFLAGS_dev-energymodel`.

Record 5.2: `tools/net/ynl/generated/Makefile` uses `$(CFLAGS_$*)` when
compiling `%-user.o`; dry-run confirmed `ethtool-user.o` and `dev-
energymodel-user.o` are affected.

Record 5.3: The YNL generator uses each spec’s `uapi-header`; `dev-
energymodel.yaml` declares `uapi-header: linux/dev_energymodel.h`.

Record 5.4: This is reachable through building generated YNL userspace
protocol objects, not through runtime kernel execution or syscalls.

Record 5.5: Similar pattern exists throughout `Makefile.deps`: YNL
families have explicit `CFLAGS_<family>` entries to force the in-tree
uAPI header and avoid stale/missing system headers.

### Phase 6: Stable Tree Analysis
Record 6.1: `v7.0`/`v7.0.9` contain both prerequisites:
`dev_energymodel.h`, `dev-energymodel.yaml`, `typelimits.h`, and
`ethtool.h` including `typelimits.h`. Older checked tags before `v6.19`
do not contain the dev-energymodel pieces; `v6.19` lacks `typelimits.h`.

Record 6.2: Patch applies cleanly to current `7.0.y` workspace. Backport
difficulty for `v7.0.y`: clean. For `v6.19.y`: needs adjustment or
should not take the `typelimits` hunk.

Record 6.3: No equivalent related fix was found already in
`stable/linux-7.0.y`.

### Phase 7: Subsystem Context
Record 7.1: Subsystem is `tools/net/ynl`, userspace tooling for netlink
YAML-generated helpers. Criticality is peripheral to kernel runtime but
relevant to building kernel tools.

Record 7.2: Subsystem is active; recent history shows several generated
YNL family and Makefile dependency changes.

### Phase 8: Impact And Risk
Record 8.1: Affected users are developers/distributions/build systems
building `tools/net/ynl/generated`, especially with distro kernel-header
packages that lack newer headers.

Record 8.2: Trigger is building generated YNL objects for `ethtool` or
`dev-energymodel`. No unprivileged runtime trigger.

Record 8.3: Failure mode is build/tooling header dependency
inconsistency, not kernel crash or data corruption. Severity: medium as
a tools build fix.

Record 8.4: Benefit is moderate for `v7.0.y` build correctness; risk is
very low because this is a tiny Makefile-only dependency addition. Risk
rises only if applied blindly to older trees missing `typelimits.h`.

### Phase 9: Final Synthesis
Evidence for backporting: small contained build fix; applies cleanly to
`v7.0.y`; fixes incomplete YNL uAPI dependency declarations; netdev
maintainer applied patch 1; no runtime behavior or API change.

Evidence against: no crash/security/data-corruption issue; no stable
nomination; not appropriate unmodified for all older stable trees.

Stable rules: obviously correct yes; fixes a real build/tooling
dependency issue yes; important enough under build-fix exception for
`v7.0.y` yes; small/contained yes; no new API/feature yes; applies to
`v7.0.y` yes.

## Verification
- [Phase 1] `git show 46e9b0224475` verified subject, body, tags,
  author, committer, and `+3/-1` diff.
- [Phase 2] Diff verified only `tools/net/ynl/Makefile.deps` changes.
- [Phase 3] `git blame` and `git log` verified changed-line history and
  related YNL dependency fixes.
- [Phase 4] `b4 dig`, `b4 dig -a`, `b4 dig -w`, and saved mbox verified
  original lore thread, recipients, one revision, and patch 1
  application.
- [Phase 5] `rg`, `git grep`, `ReadFile`, and `make -n` verified how
  `CFLAGS_$*` reaches generated object builds.
- [Phase 6] Tag/ref checks verified affected code in `v7.0.y`; `git
  apply --check` verified clean application to current tree.
- [Phase 8] No runtime reachability was found; impact is limited to
  tools build/header dependency behavior.

Backport this to `v7.0.y`; avoid applying it unmodified to older stable
trees that lack `typelimits.h`.

**YES**

 tools/net/ynl/Makefile.deps | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/net/ynl/Makefile.deps b/tools/net/ynl/Makefile.deps
index 08205f9fc5257..cc53b2f21c444 100644
--- a/tools/net/ynl/Makefile.deps
+++ b/tools/net/ynl/Makefile.deps
@@ -15,9 +15,11 @@ UAPI_PATH:=../../../../include/uapi/
 get_hdr_inc=-D$(1) -include $(UAPI_PATH)/linux/$(2)
 get_hdr_inc2=-D$(1) -D$(2) -include $(UAPI_PATH)/linux/$(3)
 
+CFLAGS_dev-energymodel:=$(call get_hdr_inc,_LINUX_DEV_ENERGYMODEL_H,dev_energymodel.h)
 CFLAGS_devlink:=$(call get_hdr_inc,_LINUX_DEVLINK_H_,devlink.h)
 CFLAGS_dpll:=$(call get_hdr_inc,_LINUX_DPLL_H,dpll.h)
-CFLAGS_ethtool:=$(call get_hdr_inc,_LINUX_ETHTOOL_H,ethtool.h) \
+CFLAGS_ethtool:=$(call get_hdr_inc,_LINUX_TYPELIMITS_H,typelimits.h) \
+	$(call get_hdr_inc,_LINUX_ETHTOOL_H,ethtool.h) \
 	$(call get_hdr_inc,_LINUX_ETHTOOL_NETLINK_H_,ethtool_netlink.h) \
 	$(call get_hdr_inc,_LINUX_ETHTOOL_NETLINK_GENERATED_H,ethtool_netlink_generated.h)
 CFLAGS_handshake:=$(call get_hdr_inc,_LINUX_HANDSHAKE_H,handshake.h)
-- 
2.53.0