From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (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 268F63A7835 for ; Wed, 29 Apr 2026 08:44:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777452289; cv=none; b=s9DGplYu1OfJzPTDGJIMHLfJIBsNHK3NzNaDtUiCTNKZgwLy/7gndLtn6HzNTw6bb7mvWzDwyP5/Z3D0PGWypT7j9YN9ao7f+Ngq4dnijUglii5goIXitenH1R+PrnLnuvb9y2tY68rKkl7kJQd4ima3ylLj/3ES9f6uB3qJuFA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777452289; c=relaxed/simple; bh=vQw+J2n9l7JWwR4OLVZHYMsIy+4U//bbbR02TWAcAfA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dglxQRXLmGOmPbPcitjzOHq9UU6eihMcqkDU6MuIGar2Kb4pmip0bWYqvq+okxuEeB1btiMoUX6p7jIG9KesT1zigBpY5tkVMDSoakgHDKV8AfOf159jp9nx/7PNkXCxUMNjXc+tBPHGin/44pvcEgu7A8j+hUodB/XdUWv4OfQ= 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=T12NpqaN; arc=none smtp.client-ip=209.85.128.48 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="T12NpqaN" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso125956275e9.1 for ; Wed, 29 Apr 2026 01:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777452286; x=1778057086; 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=cCydmE9F5QyshyzuRLKQXRbIggXPpAhdvWsPxiJRJes=; b=T12NpqaNrvkyXDLyR0M2Ho/Obq1BFxTRaEwX+4EafNZl7wXD49ZOZMWKuu/l1v4Fuy GEWldN5XY2z34CO0COH4zvz8KU0qv7OV9JltqGs1AWPdrLkTYoa3vvqxHl0oVO5nAzdr OizGsaIVXSWaS1cfbezL/sDgKBjh1Fi8ldAB23fZmNuuA7S7O0Giz93RGIgu20k0qTuB e/ID+nCX5dPCOHFpYaqlIs3h8YVepulewOYA1wWIrw8ErHOOci2gNtcVqrp9RPnoRW7/ RPf/dCh0ECFthDGVd9P7WMbLob+PkcVavpdInW6giIyPaiXqmdgrF2iQCAbwiZcnbkMY Lmeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777452286; x=1778057086; 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=cCydmE9F5QyshyzuRLKQXRbIggXPpAhdvWsPxiJRJes=; b=ob1jFHgaZfFJOZYQsUOUoMKS1mIyVRuTY9LgygqfCbjA6F7wXWyLKGKMLWIPrXzGGe cuZeS6Az8ZvS7Bx3be6YEKtBZ02NIPLl8TIbNRASCCYMJtpbYzIUYSA95Em5+NlQWlIo l29GEEPiIrCyapZ7eNTTzbUtU3ouaYLA8DIVhMTDStQyyg3vG1XrW7xHEUEPy4B+WQ4i UlyImAxUFbe7fLkldfOKPCrsVa4EoPfqJR0IXKL+P9NVilZR7q6lzWigzkbyo+a23Bdg Z+Nzdcd2lUTaAMuH9f2WiqFNo2ivWA0OQ1GzMgdkUMFNH/TprH414wwKE6QYTK3kzzuB lgBQ== X-Forwarded-Encrypted: i=1; AFNElJ/M2EcoEufB9KUXyiEjdeQJY8R15x93tEQbHNVuUIen6rIZY2fH1st0lWhxTpiBllnHDg0XWoUfmJMPv60=@vger.kernel.org X-Gm-Message-State: AOJu0YwY/y48lwnP74O03GA1SU4CzsTQMcAw066rM3LVOXQK1fSrpH02 uZt6QPJCiUNduLNePXvr+bkWowWI7VuavXwiJsWH7FM0DsK/C2o5Semr X-Gm-Gg: AeBDietfJr2dzIv4m4hWgOnfm5gBkbpgag0HNgHXIAeqrQxUADQhoKrbiE5Xp7p/KOA 2ZEYBXYFr5VOyB6kZq9yxCi0OwYm4SbwkP3ymKG/SxRz6t8biZEX/e6CQr9K/Wrvg7rfMeXc4E9 dBz1gmzMZJITtJgD1IGWf5VqUJOhlsIVg+fZilsyR+bMrrrsHjKIp2Imp+r6jafPG6HURucxZyZ mY4V8qx03ex7t1yNQiVyNLILhunToNIsmNlhhG8/06M66SdotL7I6OIbtifsDeqqIafGSMg/a+B ah+ajsibmToqDe5LIrpsjVp2vu6hyK1pHTb8jgNOI6XS7idFTVUqg3v+CN4NguLkQxTBbWRpNPq gNSE7kgNbEQbQY1zHJ3tPWKE6QRo2+L/+5uDI3QWEHmMwK+djMKAEZf9Abdghpexm3FxAUh8sPM aDh/pT32b+6tMfepvLcTrClEVDkFrPnDUH8R2Y5sbQm/iC4Yf2s0aKt2ydtcbBJXbgHSL74X03E cZ24uh7NsgVbhaH X-Received: by 2002:a05:600c:4e47:b0:48a:5574:3a5d with SMTP id 5b1f17b1804b1-48a7b51afc3mr50781275e9.7.1777452285818; Wed, 29 Apr 2026 01:44:45 -0700 (PDT) Received: from localhost.localdomain ([2a05:6e02:1135:da10:ada7:48a3:13c3:5e89]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a7bc1cbf3sm43925335e9.5.2026.04.29.01.44.44 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 29 Apr 2026 01:44:45 -0700 (PDT) From: Hasan Basbunar To: Daniel Borkmann Cc: Alexei Starovoitov , Andrii Nakryiko , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, Hasan Basbunar Subject: [PATCH v2] bpf: bpf_dbg: fix off-by-one in cmd_select Date: Wed, 29 Apr 2026 10:44:41 +0200 Message-ID: <20260429084441.22089-1-basbunarhasan@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260428100109.56572-1-basbunarhasan@gmail.com> References: <20260428100109.56572-1-basbunarhasan@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 bpf_dbg's interactive 'select ' command, documented in the file header ("select 3 (run etc will start from the 3rd packet in the pcap)") to use 1-based packet indexing, advances the pcap cursor one packet too many. The loop in cmd_select(): pcap_reset_pkt(); /* cursor on packet 1 */ for (i = 0; i < which && (have_next = pcap_next_pkt()); i++) /* noop */; calls pcap_next_pkt() N times to reach packet N, but pcap_next_pkt() validates the packet at the cursor and then advances past it. After N calls the cursor is on packet N+1, so 'select 3' positions on packet 4, 'select 4' on packet 5, etc. To land on packet N the loop must advance the cursor only N-1 times. Reproduction (deterministic, no kernel needed): build bpf_dbg from the unmodified tree, synthesize a pcap with N>=2 packets each with a distinct payload byte, and drive 'select 1 / step 1 / quit'. Before this fix, 'select 1' shows packet 2's payload. After this fix, 'select K' shows packet K for all K in 1..N, and 'select N+1' correctly errors with "no packet #N+1 available!". Cloudflare's downstream mirror at github.com/cloudflare/bpftools carries the same defect. Fixes: fd981e3c321a ("filter: bpf_dbg: add minimal bpf debugger") Signed-off-by: Hasan Basbunar --- Changes in v2: - Drop the pcap_next_pkt() boundary change (>= -> >). As correctly pointed out by Sashiko AI on the v1 thread, that change was wrong: when the last packet body ends exactly at the mmap boundary (the common case for pcap files with no trailer), the relaxed check let pcap_next_pkt() advance the cursor to pcap_ptr_va_start + pcap_map_size and return true. The cmd_run() do/while loop then re-entered its body, called pcap_curr_pkt() at end-of-mmap, and bpf_run_all() dereferenced hdr->caplen / hdr->len out of bounds. The original >= comparison is correct: when the body ends at the boundary it returns false without advancing, and the loop exits cleanly. The cmd_select() 1-based fix below is sufficient and self-contained; pcap_next_pkt() is left untouched. - v1: https://lore.kernel.org/bpf/20260428100109.56572-1-basbunarhasan@gmail.com/ tools/bpf/bpf_dbg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/bpf/bpf_dbg.c b/tools/bpf/bpf_dbg.c index 00e560a17baf..4895602ab37d 100644 --- a/tools/bpf/bpf_dbg.c +++ b/tools/bpf/bpf_dbg.c @@ -1141,7 +1141,7 @@ static int cmd_select(char *num) pcap_reset_pkt(); bpf_reset(); - for (i = 0; i < which && (have_next = pcap_next_pkt()); i++) + for (i = 1; i < which && (have_next = pcap_next_pkt()); i++) /* noop */; if (!have_next || pcap_curr_pkt() == NULL) { rl_printf("no packet #%u available!\n", which); -- 2.53.0