From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75C6B3CC9FF for ; Sun, 3 May 2026 14:15:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777817732; cv=none; b=V13yWNxsQAs1nrLzn9Q03kT78v6ZeWPgggUIAE3etlB9bG8PLokhXVeizHv1816HuC1nHmbafqt+PMZQ6nzpuzE0O2fXSCQio5inecghASsOKW9qa0+WH0L+qqYNTj51c12NNgqtCV3uVFKoXTMD+Zci6bDsAj1Jkz5f05Arr5Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777817732; c=relaxed/simple; bh=/3d3YUB84LBvSg8RhpQQfhKFPCfmZHQblYjmVcQdYRA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f1rimYOLYGW0l2GBifup3frRLxnQyALS7d0apDMmN9g9/MIAgkwDc0f9lZljuuQ8RlIiWdkUGrN51aJVMpLW9gAIUexBMPWFlnYeXKFjm1pvaINhbf6f1PLxCaoNXz//klaNdTGTRQWWhGA5zJ/erGR1EpBt9u8h68E4lLtlqbM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=rOIkYowp; arc=none smtp.client-ip=209.85.222.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="rOIkYowp" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-8cb20bcff5aso318520485a.3 for ; Sun, 03 May 2026 07:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777817730; x=1778422530; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=SPYl+D5Z/0OwSvKuu86ylxC+ZLb/TAcjdwtykkm9EUA=; b=rOIkYowpOoO7Jc3pacQKgnoZRJpVMZesXCTv7xuRmBtGD6z5TCroZvtBC7llf8OL6R cVKXTwkyoDHnXL/lg5GnMtaeYLfSPJpurBqnI7sZt1eNvWK3qCeannswuNKsB+rTAXNY tFFkB/oDfqe/G+0zAXlMWGzfq3IM9N3FCSHCTYTa5Tt9utoXhfTjq0bkvp63aLjH19dX 1izhf4+Vd4KRbEsDBzhiT+Kw9nY9ifFbefK0vz6knVzJkSif91vCzVOF5z1tpfDcu7jF /JEcXULktTIaAiDv4YnVgyzm3FnNDs6ezY05BpTgQtwH5wOtGyYV0OeFQi1+XNUZSj0n IQBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777817730; x=1778422530; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=SPYl+D5Z/0OwSvKuu86ylxC+ZLb/TAcjdwtykkm9EUA=; b=qqBvhM8FZD0Etc34RqL32MFXU+nlJNZLtwgZaet6uwW9V8jYoHO+Hct2DPAXWKcvgu XaggjW2335hPyeagku4ItocLTu6d2DCjSQXbyjE5cbLufR9rMkOxUhPrp8Xg7o9StDmr tLrhqUG87uGear9oZlSeIvS7Kot2LPWG3D8+JqFRV7HXGPlPhXL8nzE8toYxcX6k+EHz j+nhCMNPdrqlZ5irkGoCe91pFsA6tBIR75SvfrbZ1xeknkiaCJ9rF+78OivfylUnIQqY WqNJfzO11I30WlCcYc59Uev14WQ+fs1MskN7jQ4uHiN6H42Gl+vDDP3XJuxpDUngqa7T 35Pw== X-Forwarded-Encrypted: i=1; AFNElJ/NnUuo+Awf8k0dOOa9WIptWIX/ypyLL2h/Odd/F961tia2aHn16sh08s4pbzGVsri/2orF+BJ9SHTJZrs=@vger.kernel.org X-Gm-Message-State: AOJu0YzkiX5QvnWtqLcP14yFM0GbQ0u4xiUKCcdxFOkHraoa/QI/5s/x Vq7H5C/0sVT2jPxKbGfQWmzuVSUVu4I9wrEgwnrK/5TS/zx6lmuCjDLJ X-Gm-Gg: AeBDiev1Md6Cc/dggt1TfxurfvzAleWHCo78bR5O7tV7FX+0tcnDvMs9qVvTU2DgEZZ pNFtbBcj3vDVZqbCAzUOJvsp02KFiAZLVzR99REX0r8YpZ00b0gDvqubINHBjmnavu4QnHdQAmv e5ImxDCOeJQbggVMYNqzawEpLXuwNkzL6xyQtLHFJfdVIXiYZazBVPeMI93zuC8EJe/dGfcjjz8 hM7OLvnGLu3b1hm6S+oCcBeGodFdokEM8XfOP8l2v9rDBXvR4fY+UHTTzZ9yc9AA9z2BFQjwiID DcBMtXFnuxDElbQKKtD31A+8qCgDHlSX1x5Q1s2L0X6BxldDWyUfr+/rNO01z6NhBQ9j4wHhWah 1viBkMZ1YaTmFS3iC2s8Iez/Dldnn/mpfOekkD2myvvjp2ZZoiqDv8KzhxIgWDGmWv5YO+xhgjA 8w0UpHZjH35hRzwdwwAFbPT+iRq0WqmToPKDNnqpuUpaV1YKz7djHZ3Rx7rXnwL1aSp+mPu6BcT qx7Q6lvwithUT0/YJQtqcNYMpwutjg= X-Received: by 2002:a05:620a:400a:b0:8ee:21b3:2eb5 with SMTP id af79cd13be357-8fd155f2302mr958377685a.6.1777817727083; Sun, 03 May 2026 07:15:27 -0700 (PDT) Received: from server1 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8fc2938e0b9sm766261985a.9.2026.05.03.07.15.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 03 May 2026 07:15:26 -0700 (PDT) From: Michael Bommarito To: Mika Westerberg , linux-usb@vger.kernel.org Cc: Andreas Noever , Yehezkel Bernat , Andy Shevchenko , Michael Jamet , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v3 0/4] thunderbolt: harden XDomain property parser Date: Sun, 3 May 2026 10:15:04 -0400 Message-ID: X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260415123221.225149-1-michael.bommarito@gmail.com> References: <20260415123221.225149-1-michael.bommarito@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Caught a few more cases, so this addresses both your cosmetic asks on v2 and the more material changes noted in each patch below. Three independent memory-safety defects in drivers/thunderbolt/property.c are reachable when an untrusted Thunderbolt/USB4 XDomain peer responds to a PROPERTIES_REQUEST during host-to-host discovery. The peer supplies up to TB_XDP_PROPERTIES_MAX_LENGTH (500) dwords of attacker- controlled property block which the local host passes to tb_property_parse_dir() as part of the control-plane exchange that runs before any tunnels are set up. Patches 1-3 are one bug per patch: u32 overflow in tb_property_entry_valid(), short-dir_len OOB+underflow in __tb_property_parse_dir(), and unbounded recursion in the same. Patch 4 is three KUnit regression cases exercising all three. All three defects are OOB-read or DoS at worst. No controlled OOB write is reachable through the parser; parse_dwdata()'s destination is a freshly kcalloc'd buffer sized by entry->length. Operators who do not need XDomain host-to-host discovery can disable the path entirely with thunderbolt.xdomain=0 on the kernel command line. Reproduced on v7.0-rc7 + CONFIG_KASAN=y + CONFIG_USB4_KUNIT_TEST=y via the KUnit suite in patch 4. Pre-fix on a v7.0-rc7 + patch 4 kernel: u32_wrap fails with a KASAN use-after-free trace in __tb_property_parse_dir() (the parser reads ~16 GiB past the block); recursion fails with KASAN + an Oops on RIP=0 as the parser exhausts its guard page. dir_len_underflow returns NULL on pre-fix because the downstream content_len = dir_len - 4 underflow makes the entry walk bail at tb_property_entry_valid(); the UUID kmemdup over-read is silent here because KASAN-Generic's slab redzones do not flag a 4-byte over-read into the kmalloc-chunk tail. Treat dir_len_underflow as the post-fix invariant pin; u32_wrap and recursion are the active pre-fix detectors. Post-fix (all four patches): all three pass cleanly with KASAN active. Changes since v2 ---------------- Material: - Patch 2/4: move "dir_len < 4" reject before the UUID kmemdup in the non-root parse path. v2 placed it after, so a crafted entry with dir_offset near end of block and dir_len in 0..3 OOB-read up to 4 dwords past the block before the reject ran (dir_offset=497, dir_len=3, block_len=500 reads block[497..501]). Both that OOB and the original content_len = dir_len - 4 underflow now hit the same gate. - Patch 4/4: tighten dir_len_underflow's buffer (7 dwords, kmalloc-32) and reposition the entry (e->value=4) to focus the UUID kmemdup on the chunk tail. KASAN-Generic does not flag the 4-byte over-read into the tail, so the test remains a post-fix invariant pin (documented above); v2's wider buffer obscured even the post-fix-pin shape. - Patches 1/4, 2/4, 3/4: fix Fixes: SHA. v2 used e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable"), the wrong commit. Correct is cdae7c07e3e3 ("thunderbolt: Add support for XDomain properties"). Cosmetic (per v2 review): - Lowercase 0xffffff00 in 1/4 and 4/4 commit messages, and 4/4 code + comments. - Patch 4/4: hoist the on-wire entry layout into a single shared struct tb_test_property_entry instead of re-declaring an anonymous struct in each of the three tests. - Patch 4/4: use TB_PROPERTY_TYPE_DATA / TB_PROPERTY_TYPE_DIRECTORY constants from instead of bare 0x64 / 0x44. - Patch 4/4: convert all multi-line block comments to put the opening "/*" on its own line per the thunderbolt subsystem's coding style. Michael Bommarito (4): thunderbolt: property: reject u32 wrap in tb_property_entry_valid() thunderbolt: property: reject dir_len < 4 to prevent size_t underflow thunderbolt: property: cap recursion depth in __tb_property_parse_dir() thunderbolt: test: add KUnit regression tests for XDomain property parser drivers/thunderbolt/property.c | 32 +++++--- drivers/thunderbolt/test.c | 132 +++++++++++++++++++++++++++++++++ 2 files changed, 155 insertions(+), 9 deletions(-) -- 2.53.0