From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) (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 0C4C21509AB for ; Tue, 21 Apr 2026 17:08:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776791341; cv=none; b=WaOZSfirnlJNKC2t/fr/ITLamZFMOBcx0eso4JL+UkjNIXS2N/33wZEP73Rbff1YcPgKu21gWTRGdQYA9/PmdOtz10ZcQufvfGJvgTAavOtNp1uvtmUJNRJZg51ocWPWD9lQb2KgPTGQMQk2PAtxEdaC93rPVccGDXSt9UGsnJg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776791341; c=relaxed/simple; bh=m44O0dwBKI30dD/BNVYtje8eoZK0yrU4cbkCCOY9GCM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=s8yCQ9Jvan2TwhI3C7MMx8ptKGU03QVmqHG91wyJUOAek4nPlYCKCDT/IjqpvyxWKQol20YD4hfinnNDJxjpyiTXCO/9MK8DF+nQOOsLzOJyuwTb6YI+tWXg2NHw/puXFYG9JFBxsk3jEi3VF2kq9yRVx4+AZOJ5ZcrZk1I4Hfw= 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=LRs6iQI6; arc=none smtp.client-ip=209.85.160.178 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="LRs6iQI6" Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-50fb8e9a4edso8872111cf.1 for ; Tue, 21 Apr 2026 10:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776791339; x=1777396139; 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=WFUP7oxtLw+TaklzOUYMTAsDjSFshdzQqWmKfd2xajk=; b=LRs6iQI6yZWLHSyQtiV8bkZhBNfG7qNL7IzzvxR6IeC86lglESWkXSYbrag3z7jqQk 0RAcH0QJLDlryaHP39YyNQw3faHf5bB38DtkEzJn9ERLwm8UBFqOttbNkkkBNuF8EC5N f3cXiFsu41vmYiLyL6vJ+G6tfryzfDuCsnrjjkkh+in4Be6dBjxDo+ymsBarhdX+V3/z VZHaHrupZD9d2FNtn2DpnvxIeXcX6xD4NCvfZGQNNOEw6dYOPCkSAmIeE27ntIQ5YDnh rS8B4apd1ZrjtrnjP9cZkgguMlHlepyOS0XTS3zy0qgoX2/u1PWqNTvXVc4pYqGSld1/ 5aFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776791339; x=1777396139; 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=WFUP7oxtLw+TaklzOUYMTAsDjSFshdzQqWmKfd2xajk=; b=r47QexXWvyaRH+kt/pTc2D2Mu+icZRbDrNbDE5RsIwUNJuREqzsKr3quCaVkw7/xgZ y9jPilofiVelxReeFiki7Jc2TAbbuYCJLv6g8fnsg6CaLUIrd4fWjuH3NX77vxrE+Qj9 iS2A86USiNiqXeTU+5KGWFYjIN18W4KRk6tHVA6lOp3sJ7NaAn914PpXp76Z4bvkbLBe DxYFyhjcyJ1t2aBg7hYVJ81xW8yJpNcZT3iTJY2WkUDGJrVXrkdrFbyxnL7tP+Z/funf TpHnhttmlRidBD3wF8sFitUx2eyiC80srtG0GazxBeqpxQGDL2IAx29TgxShpleigle8 98rg== X-Gm-Message-State: AOJu0YxGRLcXyieqM+eU9nmqVAl7aMgj2iS7b+LC3RyHaRfYFM7ttiSG xXfug6ir0b1653Qpv016VsX6oN4XFlp9pknMAAsZQ/RAeQw9sd6+wo3/GDUepwcF X-Gm-Gg: AeBDiesUH67QcQkieIHnYevAnQh/OeUxTtTZ8YsobYGMcbOBX8gl3sHDMQ7zMwJjtGZ nzGFockavEzXHwcb9vPhvoBP7/MDwtb8NswEwrvvy0gjn34f+VnOV2xx33dJ345evOhZJeBPcxf m5KxIwEX2FyLFF/YCy2KGPBpoiqMz0R2UoE7axDg+Lw5bFIGcPAfptvlL/HwrXpF0qjjoi0I8hO Eb/dCo6JhaDenNH8n8VcXJvOUd86p3TWx2v3YueApye/WO/mfU57RyMt820KdAa7f2QT/cE8RLm oSh+czXblfUuz9BZIuyxw6T8InfX9GaDoQzGuzL970hAc4HeYZRu/LJUTCy4SoxDoue7gM5viad 50CDCFCD08f9LRTWamLmv9OrVwxeDPvsO71nBKHm/2NtIwJGhx/YJiLf5ZjvYbBBhvUn+RLuDe7 rLMtGbH59LKsbwmp3/aNIKx4SX406MAV+YemQbmrNOBHLJ/O+0dIKSuc09y/oDqPO76ZRC4tPfp tdm/TzZE/vOhF2mKxNPxvpxqXLWn3s= X-Received: by 2002:ac8:5ace:0:b0:50f:ad91:8902 with SMTP id d75a77b69052e-50fad918c7amr93780241cf.37.1776791338948; Tue, 21 Apr 2026 10:08:58 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50fb92db861sm13134471cf.5.2026.04.21.10.08.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2026 10:08:58 -0700 (PDT) From: Michael Bommarito To: Marcel Holtmann , Luiz Augusto von Dentz , linux-bluetooth@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Soenke Huster , "Michael S . Tsirkin" , virtualization@lists.linux.dev Subject: [PATCH v3 0/2] Bluetooth: virtio_bt: harden rx against untrusted backend Date: Tue, 21 Apr 2026 13:08:43 -0400 Message-ID: <20260421170845.3469513-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Respin of the virtio_bt rx hardening patch, split per Luiz's request on the v2 thread: https://lore.kernel.org/linux-bluetooth/20260421151659.3326690-1-michael.bommarito@gmail.com/ v2 bundled two independent hazards in one commit and the commit message got convoluted trying to explain them together. This v3 keeps each hazard in its own patch so the rationale for each is self-contained. Patch 1/2 keeps the original v1/v2 concern: virtbt_rx_work() calls skb_put() with a used.len the device controls, with no validation against the 1000-byte buffer we actually exposed to virtio via sg_init_one(). Checking against skb_tailroom() is not enough because alloc_skb() can leave more tailroom than 1000 bytes due to slab padding. len == 0 is also accepted, which lets an empty skb reach virtbt_rx_handle() where the pkt_type byte is then read from uninitialized memory. 1/2 defines VIRTBT_RX_BUF_SIZE, reuses it in alloc_skb() and sg_init_one(), and gates virtbt_rx_work() on [1, VIRTBT_RX_BUF_SIZE] with bt_dev_err_ratelimited() on the drop path. Patch 2/2 closes a residual short-payload hazard found during v2 pre-send review. After 1/2 restricts used.len to [1, 1000], a one-byte completion still reaches hci_recv_frame() with skb->len pulled to 0. If that byte was HCI_ACLDATA_PKT, the ACL-vs-ISO classification fast-path in hci_dev_classify_pkt_type() dereferences hci_acl_hdr(skb)->handle whenever the HCI device has an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of uninitialized RX-buffer data. The same hazard shape exists for every packet type because none of the switch cases in virtbt_rx_handle() checked skb->len against the per-type minimum HCI header. 2/2 requires skb->len to cover the fixed header size for the selected type (event 2, ACL 4, SCO 3, ISO 4) before calling hci_recv_frame(); drop ratelimited otherwise. Unknown pkt_type values still take the original kfree_skb() default path. Both patches carry the same Fixes: 160fbcf3bfb9 and Cc: stable@ as the v2 commit, because both hazards have existed since the driver switched to skb_put() for used.len handling. Fresh runtime repro of the original skb_over_panic on an unpatched tree and a clean reject log with 1/2 applied are attached in the evidence bundle referenced from the v2 thread; no runtime change between v2 and v3 beyond the split (the final tree after 1/2+2/2 is byte-identical to the v2 commit). Prior public versions of this patch on linux-bluetooth: v1: <20260418000138.1848813-1-michael.bommarito@gmail.com> v2: <20260421151659.3326690-1-michael.bommarito@gmail.com> Michael Bommarito (2): Bluetooth: virtio_bt: clamp rx length before skb_put Bluetooth: virtio_bt: validate rx pkt_type header length drivers/bluetooth/virtio_bt.c | 39 ++++++++++++++++++++++++++++------- 1 file changed, 32 insertions(+), 7 deletions(-) -- 2.53.0