All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Nicholas Dudar" <main.kalliope@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT
Date: Fri, 17 Jul 2026 19:16:20 +0000	[thread overview]
Message-ID: <20260717191621.0D7DC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260717190544.257306-2-main.kalliope@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch implements BPF_SDIV and BPF_SMOD for the 64-bit PA-RISC JIT but omits the 32-bit JIT, causing signed divisions to be silently miscompiled as unsigned.
--

--- Patch [1]: [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT ---
commit 5e5d75e62e2afee7aac7d5510ab28785201de9f5
Author: Nicholas Dudar <main.kalliope@gmail.com>

bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

This commit adds support for signed division and modulo (BPF_SDIV and
BPF_SMOD) to the 64-bit PA-RISC BPF JIT. It passes the signedness check
down to the emission functions and introduces signed libgcc helper
wrappers.

> bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT

[Severity: High]
This is a pre-existing issue, but does the 32-bit PA-RISC JIT still
miscompile signed divisions as unsigned?

While this patch correctly implements BPF_SDIV and BPF_SMOD for the 64-bit
JIT, arch/parisc/net/bpf_jit_comp32.c appears to still unconditionally
accept these instructions without checking if insn->off == 1.

In arch/parisc/net/bpf_jit_comp32.c:bpf_jit_emit_insn():

    case BPF_ALU | BPF_DIV | BPF_X:
    case BPF_ALU | BPF_DIV | BPF_K:
    case BPF_ALU | BPF_MOD | BPF_X:
    case BPF_ALU | BPF_MOD | BPF_K:
        /* ... */
        emit_alu_r32(dst, src, ctx, BPF_OP(code));

And then in emit_alu_r32():

    case BPF_DIV:
        emit_call_millicode($$divU, lo(rd), lo(rs), op, ctx);
        break;
    case BPF_MOD:
        emit_call_millicode($$remU, lo(rd), lo(rs), op, ctx);
        break;

Because the JIT silently compiles signed division as unsigned ($$divU),
and the eBPF verifier calculates memory bounds assuming a signed result,
could this verifier-JIT desynchronization be exploited to bypass bounds
checks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717190544.257306-1-main.kalliope@gmail.com?part=1

  reply	other threads:[~2026-07-17 19:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17 19:05 [PATCH bpf-next 0/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc JITs Nicholas Dudar
2026-07-17 19:05 ` [PATCH bpf-next 1/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc64 JIT Nicholas Dudar
2026-07-17 19:16   ` sashiko-bot [this message]
2026-07-17 22:36     ` Nicholas Dudar
2026-07-17 19:52   ` bot+bpf-ci
2026-07-17 20:58     ` Nicholas Dudar
2026-07-17 22:27     ` Nicholas Dudar
2026-07-17 19:05 ` [PATCH bpf-next 2/2] bpf, parisc: Add support for BPF_SDIV and BPF_SMOD in the parisc32 JIT Nicholas Dudar
2026-07-17 19:27   ` sashiko-bot
2026-07-17 23:01     ` Nicholas Dudar

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=20260717191621.0D7DC1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=main.kalliope@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.