BPF List
 help / color / mirror / Atom feed
From: Jiayuan Chen <jiayuan.chen@linux.dev>
To: 梅开彦 <kaiyanm@hust.edu.cn>, bpf邮件列表 <bpf@vger.kernel.org>
Cc: "dzm91@hust.edu.cn" <dzm91@hust.edu.cn>,
	"dddddd@hust.edu.cn" <dddddd@hust.edu.cn>,
	"hust-os-kernel-patches@googlegroups.com"
	<hust-os-kernel-patches@googlegroups.com>
Subject: Re: BUG: WARNING in bpf_convert_ctx_accesses on narrow loads of bpf_tcp_sock u64 fields
Date: Fri, 16 Oct 2026 18:08:47 +0800	[thread overview]
Message-ID: <118feacc-7f1b-42bf-8951-986e4d37319d@linux.dev> (raw)
In-Reply-To: <7a8ff335.1024c.1a14395f3e5.Coremail.kaiyanm@hust.edu.cn>


On 10/16/26 3:21 PM, 梅开彦 wrote:
> Our fuzzer tool discovered a verifier-bug (WARNING) vulnerability in the BPF
> subsystem. `bpf_tcp_sock_is_valid_access()` accepts a 4-byte load at offset
> 0x54/0x5c — the middle of the u64 fields `bytes_received`/`bytes_acked` —
> and forwards the instruction unchanged to
> `bpf_tcp_sock_convert_ctx_access()`. The converter has no case for these
> offsets, so it returns 0 and the verifier trips
> `verifier_bug("error during ctx access conversion (0)")`.
>
> Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
> Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
>
> ## Root Cause
>
> A ctx load on a `PTR_TO_TCP_SOCK` register is validated by
> `bpf_tcp_sock_is_valid_access()` (net/core/filter.c) and rewritten by
> `bpf_tcp_sock_convert_ctx_access()` — and the two disagree on which
> offsets exist.
>
> The validator's switch only special-cases the u64 field starts
> `bytes_received` (0x50) and `bytes_acked` (0x58), which require
> `size == 8`; every other offset falls to the default case, which
> accepts any 4-byte-aligned offset in the struct with `size == 4`:
>
> ```c
> 	switch (off) {
> 	case offsetof(struct bpf_tcp_sock, bytes_received):	/* 0x50 */
> 	case offsetof(struct bpf_tcp_sock, bytes_acked):	/* 0x58 */
> 		return size == sizeof(__u64);
> 	default:
> 		return size == sizeof(__u32);
> 	}
> ```
>
> The converter, in contrast, only knows the exact field starts: its
> switch covers every field of `struct bpf_tcp_sock` and has no default
> case — an unmatched offset generates no instructions and returns
> `cnt = 0`, which the fixup pass treats as a verifier-internal error
> (`verifier_bug("error during ctx access conversion (0)")`).



Thanks for your report !



I think the issue is that a program can do:
'''
     tp = bpf_tcp_sock(listener);
     /* +0x54 is in the middle of the u64 bytes_received */
     unsigned hi = *(unsigned *)((char *)tp + 0x54);
'''


bpf_tcp_sock_is_valid_access() allows this, but
bpf_tcp_sock_convert_ctx_access() has no idea how to handle such an
offset.

I think we can just disallow the narrower access:

diff --git a/net/core/filter.c b/net/core/filter.c
index ba536be2915f..f0eae1c14b2f 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -7600,8 +7600,8 @@ bool bpf_tcp_sock_is_valid_access(int off, int 
size, enum bpf_access_type type,
                 return false;

         switch (off) {
-       case offsetof(struct bpf_tcp_sock, bytes_received):
-       case offsetof(struct bpf_tcp_sock, bytes_acked):
+       case bpf_ctx_range(struct bpf_tcp_sock, bytes_received):
+       case bpf_ctx_range(struct bpf_tcp_sock, bytes_acked):
                 return size == sizeof(__u64);
         default:
                 return size == sizeof(__u32);


      reply	other threads:[~2026-10-16 10:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  7:21 BUG: WARNING in bpf_convert_ctx_accesses on narrow loads of bpf_tcp_sock u64 fields 梅开彦
2026-10-16 10:08 ` Jiayuan Chen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=118feacc-7f1b-42bf-8951-986e4d37319d@linux.dev \
    --to=jiayuan.chen@linux.dev \
    --cc=bpf@vger.kernel.org \
    --cc=dddddd@hust.edu.cn \
    --cc=dzm91@hust.edu.cn \
    --cc=hust-os-kernel-patches@googlegroups.com \
    --cc=kaiyanm@hust.edu.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox