From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.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 8C668355803 for ; Wed, 15 Jul 2026 04:15:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784088920; cv=none; b=UR1UE5HSiWqkESD839aSobwX7bYazXlKqHSEbSE6c5pSzOip+j6AEYdmPNADZSsk09BuA+YrPAKa/L1qnWX9y1eHuxOsLJp5GtshUC006VFITFBJxXqpCJES42Uvgsgl/Xxbk/eQRAr7rL/OizWaRu1Ggso6u5q7Sq4Ma31DSvc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784088920; c=relaxed/simple; bh=16DHuToYWDY48zhMFmSTuIb8xl3je5jZqI8M9KYbD6M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QRtFAMD+d2gvOCiTt9j1DD4lPfAbo6Et4hcEfupDaiSLKqUahv5CN82YfYYXE3x3l7sm6gM7cngWkzHRfOA5f+OYcuadEVUL6tZ/KjJ+TV48Juw/02VDTJpBE7w9G1eIatC0LXJXfu4VmV7tnsOO6CBS1n/uJ45boxmlZmiV+yc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=WZkTsYJQ; arc=none smtp.client-ip=209.85.208.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="WZkTsYJQ" Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-69e08ad526cso969660a12.1 for ; Tue, 14 Jul 2026 21:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784088917; x=1784693717; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=f5HqzaGK1TaHR8NVrhGDd/lA3x1fxnTO8aG7VNVpk8s=; b=WZkTsYJQvvAdyF7lRNbHfK2PJ8PUqYJBllwwU9sVToozvYWYR10L8UH4S7Jt5Ea9fc AVeGNGMLMwvDYP38QNvzH3aDwCaoAiYv7cyb+7lbdbQ1RGaRvE6zje7ce1xe+/9oYoa8 COy4shESM3SbP9ybL2fhuTVAKRbEMVP0CELZ6HOzXiTOkNUo2tgSaiZiPCyLQF8eEAox 9m4DrLSQ/u5EDLoieBLYheX+YlUFgoM2Wtfxyz6WCLpIG88AL4K7EOBjN1kS1UkYNV19 lztQKadKV72YWVnL0KoO5VNy/YygwQN9hhZTi5Af+mhcsa5PIbrZxCcBvqKwFIEwEfbb ok1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784088917; x=1784693717; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=f5HqzaGK1TaHR8NVrhGDd/lA3x1fxnTO8aG7VNVpk8s=; b=qFmxP/id5sESOasu1HZZ1iwu6d/LH4gh8XY5Q3Pw0kRNP/EdjIjcMZf8673GRsthaV Ga3Q7jvNQohV+HYHCGblslacUuMMojlDDdEXAW35HrGqzVWjQezirAY5Nhmql/xOyg9Q ChM9X/LPxYVDmZPjUDPXIJGIbqMZzUd1MnAZvMmMWY82tZwroqDir6TtESbSLfGQqYy5 rdlLVnkRAXcY+C7rXbDZswwlyjyc5sW+GwGY0Bkp/+3lZihPnTATba4TxEQ9lH9xUrqp nC0l/ia50iBhmpviLcf2qfSkKo2WjMgQbcJqW7tdo1YpvxpeHeXe4AQ37HqpvPSsMuav YnJA== X-Forwarded-Encrypted: i=1; AHgh+RrI47fBykED63h5u9oA09doSRW6Ygu6JDM1gnWjnqjMW+DheHtHQzqRypyC4z1SQkCI306xW3tjOulvUjuLA+E=@vger.kernel.org X-Gm-Message-State: AOJu0YxcQKfnDV66n+RHGJzYfJt9MnOGJFATG9I5J/VQG+IA4TyGUOSI 0vBoET7ZfThBnO0LUBuH7i2UXax4Ni8mxeuHJwFAC6AqP9wr1i2YX/jzO4rUO4dagD4= X-Gm-Gg: AfdE7claTaixmHQF9KhHg72ufloonI7LOTFNU7HhJrSUSpxEBG/108FUBvh0iWpCXws fCSRl/hRrF2fuzHRXRsv1PtSNrwiOjgTnNVvC1Rcog3qcMpWk1iU14aUHDYHM0OyuhBBAv5HrR0 +pFc3GPPiZU535W2DqKPQksxEJ7Neo9Warp3IuMKuTYBMwA0ah18hwsYf6O/5CFGOjlZdKrsOTe GZFPQW+08hmModM+8Mmv1d5RgCpWcED9LOt/4w48pM0qijLouCTT7rTKcWKi/RjJGwsisvm5yyR A9lcMi/cPWU1BJjl0FzWZ/X25LEWNMsOKK2nbCrrl2C17fJN6/GpDUwjWV0fMEBRwnTVU+wK8IS aFzbrxSgbeKS4jcO6yeLwLI+36XzHvq/uja86JckO/TpvRQuXsroaTuh5wd/W+AVzIXi7jW+k4b 03sNjo9UqrmaiAxh4WPVWGrano7+620JPe X-Received: by 2002:a17:907:3f91:b0:c16:67d8:7a0f with SMTP id a640c23a62f3a-c1667d87c1cmr391012266b.28.1784088916647; Tue, 14 Jul 2026 21:15:16 -0700 (PDT) Received: from u94a (27-51-89-168.adsl.fetnet.net. [27.51.89.168]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84a4f238f75sm2427757b3a.9.2026.07.14.21.15.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 21:15:15 -0700 (PDT) Date: Wed, 15 Jul 2026 12:15:07 +0800 From: Shung-Hsi Yu To: Sun Jian Cc: bpf@vger.kernel.org, Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Eduard Zingerman , Emil Tsalapatis , Jiri Olsa , John Fastabend , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Shuah Khan , Song Liu , Yonghong Song , Matt Mullins , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH bpf v5 2/2] selftests/bpf: Cover negative buffer pointer offsets Message-ID: References: <20260714093846.18159-1-sun.jian.kdev@gmail.com> <20260714093846.18159-3-sun.jian.kdev@gmail.com> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260714093846.18159-3-sun.jian.kdev@gmail.com> On Tue, Jul 14, 2026 at 02:38:46AM -0700, Sun Jian wrote: > Add verifier coverage for constant negative offsets on PTR_TO_TP_BUFFER > and PTR_TO_BUF pointers. Both programs adjust the buffer pointer by -8 > and access it at offset zero, so the negative effective start must be > rejected at load time. [...] > + const struct bpf_insn negative_var_off_program[] = { > + BPF_LDX_MEM(BPF_DW, BPF_REG_6, BPF_REG_1, 0), > + /* make var_off negative, but keep the effective access offset non-negative */ > + BPF_ALU64_IMM(BPF_ADD, BPF_REG_6, -8), > + /* one byte beyond the end of the writable context */ > + BPF_LDX_MEM(BPF_B, BPF_REG_0, BPF_REG_6, > + sizeof(struct bpf_testmod_test_writable_ctx) + 8), > + BPF_EXIT_INSN(), > + }; Come to think of it, perhaps we can add another one that test one byte *before* the start of the writable context? I understand that it won't even reach the attachment phase because after your 1st patch is applied, access to effective negative offset of will be rejected at load time, but the one that tried to access one byte before the start of writable context was what that triggered KASAN, and would be useful to have it as a regression test. Or alternatively simply change negative_var_off_program[] to be the one that test access *before* the start of context. I am not even sure if the compiler generate such pattern; if it doesn't, then this test would make future refactoring harder without much benefit. [...]