On Tue, Mar 24, 2026 at 12:46:23AM +0100, buermarc wrote:
> Hi Joel,
> 
> Thanks for the question.
> 
> On Mon, 23 Mar 2026 14:53:51 +0100, Joel Granados wrote:
> 
> > Here I have a question:
> > 
> > How is it possible that the buffer in proc_do_large_bitmap is not
> > terminated with a '\0' when writing?
> > 
> > The proc_do_large_bitmap gets called from proc_sys_call_handler and
> > before running the table->proc_handler call, the end of the buffer gets
> > set with '\0'.
> 
> This is correct, the buffer will be terminated with a '\0'.
> 
> > trailing char is '\0'. Which, in turn, means that 'c' will always get a
> > value.
> 
> I think this does not hold true. If the buffers is parsed till the end
> len can be of the same value as size in proc_get_long(), which means we
This is not the case:

1. len is calculated by doing len = p - tmp
2. tmp is the beginning of the buffer
3. p is the first character that is not a digit.

There will always be at least one ('\0') character that is not a digit.
So len will be less than size at least by one (could be more if the
string contains non digit chars). When it is parsed to the end,
len will be less than size by one.

All this holds unless the trailing '\0' is modified in some way in that
BPF call.

> do not set tr.
> 
> I will go through my current understanding for a
> write(3</proc/sys/net/ipv4/ip_local_reserved_ports>, "123", 3) = 3
> syscall. Hopefully that will make things a bit clearer, or show where I
> am mistaken.

TL;DR

> 
> In proc_sys_call_handler() we call the function (in our case
> proc_do_large_bitmap()) with the count based on the result of
> iov_iter_count(), while ensuring that the buffer contains a trailing
> '\0' char. So the buffer will contain '123\0', that is correct. The
> passed count will does not change it will still be 3. I used bpftrace to
> check my assumption as I don't know the iov_iter struct all that good
...
>     # On x86_64, local chars could be at the end of the stack frame?
>     sudo bpftrace -e 'kprobe:proc_do_large_bitmap {
>         $c_val = *(u8 *)(reg("bp") - 1);
>         printf("PID %d: c starts as 0x%02x (%c)\n", pid, $c_val, $c_val);
>     }'
> 
> But I must admit this was just a shot into the blue. Yet, on the
> affected host the -EINVAL results disappeared as long as the probe was
> attached. My assumption was that the eBPF trace changed which value c
> pointed to on the stack.
> 
> Best Regards,
> Marc

Best

-- 

Joel Granados