[PATCH 0/2] thunderbolt: Validate router-provided port numbers

[Daehyeon Ko <4ncienth@gmail.com>]

Two six-bit port numbers received from a router are used to index the
router's sw->ports array without first comparing them with
max_port_number. The array contains only max_port_number + 1 entries.

Patch 1 validates the port in a DP bandwidth notification before
tb_handle_dp_bandwidth_request() calls tb_port_is_dpin(). Patch 2
validates HOPS out_port at all three path-discovery sites and performs
the construction-pass check before allocating an input HopID.

I tested a private synthetic KUnit reproducer on current mainline
893e11787f78. It allocates ports 0 through 12 and supplies port 63. On
x86_64, struct tb_port is 200 bytes, so the requested allocation is
2,600 bytes and the selected object starts at offset 12,600.

The unmodified accesses produced:

  - a four-byte KASAN slab-out-of-bounds read in
    tb_port_is_dpin(), 3/3 boots;
  - an eight-byte KASAN slab-out-of-bounds read of
    out_port->remote, 3/3 boots.

With this series, both controls pass 3/3 with no KASAN report and the
complete Thunderbolt KUnit suite passes 47/47. drivers/thunderbolt/tb.o
and path.o also build with W=1 without warnings.

I have not performed hardware control-channel or HOPS injection. The DP
notification index is used before tunnel lookup or bandwidth-mode
validation. The HOPS sites are used to discover already enabled preboot
tunnels and during resume discovery; ordinary hotplug path construction
uses tb_path_alloc() instead.

The private reproducer is available to the maintainers on request and is
not included in this public series.

Daehyeon Ko (2):
  thunderbolt: Validate DP bandwidth notification port
  thunderbolt: Validate output ports while discovering paths

 drivers/thunderbolt/path.c | 27 ++++++++++++++++++++++-----
 drivers/thunderbolt/tb.c   |  5 +++++
 2 files changed, 27 insertions(+), 5 deletions(-)


base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8
-- 
2.55.0