Re: [PATCH v2 11/22] thunderbolt: Find Apple VSE capability during startup

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Infinite loop in capability parsing when a malicious Thunderbolt device presents a config space with a cyclic capability linked list.
--

commit e6dace564d4bffbe73d0c61815b1d55831634e86
Author: Sven Peter <sven@kernel.org>
Date:   Sun Sep 6 18:36:34 2026 +0000

thunderbolt: Find Apple VSE capability during startup

This commit looks up the Apple vendor-specific extended capability during
startup and stores its offset in the root switch. This enables the Apple
NHI driver to program cable information without needing to search the
router capabilities itself.

> diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
> index bf1c192ec10a5..d2832323cc360 100644
> --- a/drivers/thunderbolt/tb.c
> +++ b/drivers/thunderbolt/tb.c
> @@ -3025,6 +3025,10 @@ static int tb_start(struct tb *tb, bool reset)
>  		return dev_err_probe(tb->nhi->dev, PTR_ERR(tb->root_switch),
>  				     "failed to allocate host router\n");
>  
> +	ret = tb_switch_find_vse_cap(tb->root_switch, TB_VSE_CAP_APPLE);

[Severity: High]
This is a pre-existing issue, but does calling tb_switch_find_vse_cap expose
the kernel to an infinite loop if a malicious device is connected?

Looking at tb_switch_find_vse_cap in drivers/thunderbolt/cap.c, the capability
parsing loops indefinitely while following the next capability offset returned
by the hardware:

        do {
                struct tb_cap_any header;
                int ret;

                offset = tb_switch_next_cap(sw, offset);
                if (offset < 0)
                        return offset;
                ...
        } while (offset);

If an untrusted external device presents a configuration space with a cyclic
capability linked list (for example, where capability A points to capability B,
which points back to A), this loop will never terminate. This could cause a
localized denial of service by hanging the Thunderbolt hotplug workqueue
and pegging a CPU core at 100% indefinitely.

Should there be a cycle detection mechanism or an iteration limit added to
the capability traversal logic to prevent this?

> +	if (ret > 0)
> +		tb->root_switch->cap_vsec_apple = ret;
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260906-b4-apple-soc-tbt-v2-0-1f80085f93fb@kernel.org?part=11