All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mingpei CAO <caomingpei@gmail.com>
To: bpf@vger.kernel.org
Cc: andrii@kernel.org, eddyz87@gmail.com, ameryhung@gmail.com,
	qmo@kernel.org, Mingpei CAO <caomingpei@gmail.com>
Subject: [PATCH bpf v2 0/3] libbpf: Validate struct_ops member offsets
Date: Sun, 13 Sep 2026 14:52:30 +0000	[thread overview]
Message-ID: <20260913145233.1446643-1-caomingpei@gmail.com> (raw)

A local struct_ops type can contain a bitfield absent from the
corresponding kernel BTF type. libbpf checks whether data for an absent
local member is zero.

For a bitfield, member->offset contains the bit position and field width.
bpf_map__init_kern_struct_ops() used the full value to create a data
pointer before checking the member range. libbpf_is_mem_zeroed() could
then read outside the local struct_ops data.
ASan reported a SEGV. bpf_map__init_kern_struct_ops() also failed to check
offsets for non-bitfield members.

Patch 1 rejects local and kernel bitfields before reading member data.
Patch 1 also checks every local and kernel member range before creating a
data pointer.

Patch 2 represents unsupported bitfield storage as padding in generated
skeletons. The padding preserves the struct_ops map and keeps supported
fields at their declared BTF offsets.

Patch 3 checks the bitfield rejection, the generated C structure, and an
out-of-range non-bitfield member.

AI assistance was used in preparing this series. I independently reviewed
the changes and reproduced the issue and fix.

Changes since v1:
- name the local member and the matching kernel BTF type;
- remove JIT, compiler, and initialization details from the problem summary;
- check every offset used to create a data pointer;
- represent unsupported bitfield storage as padding while preserving the
  struct_ops map and supported field offsets;
- test adjacent bitfield members and an out-of-range non-bitfield member.

Link: https://lore.kernel.org/bpf/20260910172340.1467764-1-caomingpei@gmail.com/

Mingpei CAO (3):
  libbpf: Validate struct_ops member offsets before data access
  bpftool: Keep struct_ops field offsets when skipping bitfields
  selftests/bpf: Cover struct_ops bitfield and offset validation

 tools/bpf/bpftool/gen.c                       | 147 ++++++++++++------
 tools/lib/bpf/libbpf.c                        |  80 ++++++++--
 .../bpf/prog_tests/test_struct_ops_module.c   |  91 ++++++++++-
 .../selftests/bpf/progs/struct_ops_module.c   |  17 ++
 4 files changed, 272 insertions(+), 63 deletions(-)

base-commit: 7d70a0b02d262971201fdd1e221586bdd95c2910
-- 
2.43.0

             reply	other threads:[~2026-09-13 14:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-13 14:52 Mingpei CAO [this message]
2026-09-13 14:52 ` [PATCH bpf v2 1/3] libbpf: Validate struct_ops member offsets before data access Mingpei CAO
2026-09-13 15:49   ` bot+bpf-ci
2026-09-13 14:52 ` [PATCH bpf v2 2/3] bpftool: Keep struct_ops field offsets when skipping bitfields Mingpei CAO
2026-09-13 15:02   ` sashiko-bot
2026-09-13 15:49   ` bot+bpf-ci
2026-09-13 14:52 ` [PATCH bpf v2 3/3] selftests/bpf: Cover struct_ops bitfield and offset validation Mingpei CAO
2026-09-13 15:03   ` sashiko-bot
2026-09-13 15:49   ` bot+bpf-ci

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=20260913145233.1446643-1-caomingpei@gmail.com \
    --to=caomingpei@gmail.com \
    --cc=ameryhung@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=qmo@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.