Re: [PATCH bpf-next 2/3] bpf: insn array: return EACCES for incorrect map access

Emil Tsalapatis
2026-01-12T19:19:03Z

On Mon Jan 12, 2026 at 1:45 PM EST, Anton Protopopov wrote:
> On Mon, Jan 12, 2026 at 6:12 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
>>
>> On Sun Jan 11, 2026 at 10:30 AM EST, Anton Protopopov wrote:
>> > The insn_array_map_direct_value_addr() function currently returns
>> > -EINVAL when the offset within the map is invalid. Change this to
>> > return -EACCES, so that it is consistent with similar boundary access
>> > checks in the verifier.
>> >
>> > Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
>> > ---
>> > kernel/bpf/bpf_insn_array.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/kernel/bpf/bpf_insn_array.c b/kernel/bpf/bpf_insn_array.c
>> > index 37b43102953e..c0286f25ca3c 100644
>> > --- a/kernel/bpf/bpf_insn_array.c
>> > +++ b/kernel/bpf/bpf_insn_array.c
>> > @@ -123,7 +123,7 @@ static int insn_array_map_direct_value_addr(const struct bpf_map *map, u64 *imm,
>> >
>> > if ((off % sizeof(long)) != 0 ||
>> > (off / sizeof(long)) >= map->max_entries)
>> > - return -EINVAL;
>> > + return -EACCES;
>>
>> -EACCES is reasonable but the other .direct_valud_addr() methods use
>> -EINVAL (array) and -ERANGE (arena). If we're going for consistency
>> can we change them all to the same error code?
>
> Would be nice, but I doubt this is possible, as this should break
> plenty of existing user space progs (for insn array userspace code
> with off != 0 actually don't exist afaik).
>

Makes sense.

Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>

> (I am also pretty fine with not doing s/EINVAL/EACCESS for insn array,
> but without this change selftests in the third patch look kinda
> weird.)
>
>> >
>> > /* from BPF's point of view, this map is a jump table */
>> > *imm = (unsigned long)insn_array->ips;
>>