linux-kernel - Re: Printing with overflow checks can cause modpost errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4940aa5a-18d0-4bcd-9125-80f5a9920627@gmail.com>
Date: Thu, 11 Sep 2025 23:08:17 -0500
From: Andrew Ballance <andrewjballance@...il.com>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 John Hubbard <jhubbard@...dia.com>, Alexandre Courbot <acourbot@...dia.com>,
 Timur Tabi <ttabi@...dia.com>, Alistair Popple <apopple@...dia.com>,
 Miguel Ojeda <ojeda@...nel.org>
Subject: Re: Printing with overflow checks can cause modpost errors

On 9/11/25 9:53 PM, Joel Fernandes wrote:
> On Thu, Sep 11, 2025 at 07:27:26PM -0500, Andrew Ballance wrote:
>> On Thu, Sep 11, 2025 at 05:31:57PM -0400, Joel Fernandes wrote:
>>> Hello,
>>> Recently some of have been running into modpost errors more frequently. Ahead
>>> of Kangrejos, I am trying to study them, the one I looked at today is truly
>>> weird, below are more details.
>>>
>>> I narrowed it down to the print statement and specifically the FFI call to
>>> printk bindings. This was first reported by Timur Tabi on CC.
>>>
>>> With CONFIG_RUST_OVERFLOW_CHECKS=y and CONFIG_RUST_BUILD_ASSERT_ALLOW=y, the
>>> following patch when applied to nova-core will fail to build with following
>>> errors. The question is why does the overflow checking fail since the
>>> arithmetic is valid, and why only during printing (and say not during the
>>> call to write32).
>>>
>>>    MODPOST Module.symvers
>>> ERROR: modpost: "rust_build_error" [drivers/gpu/nova-core/nova_core.ko] undefined!
>>> make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
>>> make[1]: *** [/home/joelaf/repo/linux-nova-rm-call/Makefile:1961: modpost] Error 2
>>> make: *** [Makefile:248: __sub-make] Error 2
>>>
>>> Any comments or thoughts?
>>>
>>
>> Io::write32 tries to do a bounds check at compile time and if it cannot
>> be done it causes a build error. it looks like because a pointer to
>> offset is passed across a ffi boundary, rustc makes no assumptions about
>> the value of offset. so it cannot do the bounds check at compile time
>> and causes a build error.
> 
> Are you saying this issue is related to iowrite32? I don't think so because
> the issue does not happen if you comment out the pr_err in my example and
> leave the write32 as it is. So it is something with the call to printk (FFI).
> 
> Why can't it assume the value of offset? All the values to compute it are
> available at compile time right?
> 
> thanks,
> 
>   - Joel
> 

This is a resend because I forgot to cc the mailing list.

it has to do with the FFI call. The value of offset can be found out at
compile time, but because a pointer is passed through, the c side could
theoretically change the value before write32 is called.
The pointer passed is const so rustc should assume that the c side does
not change offset, but looks like rustc does not do that.

as a test i created a version where a copy of offset is passed to printk
instead of offset and it compiles.
e.g:
// SNIP
let offset = <B as kernel::io::register::RegisterBase<$base>>::BASE
     + Self::OFFSET
     + (idx * Self::STRIDE);
let offset_copy = offset;

pr_err!("{}", offset_copy);
io.write32(self.0, offset);
// SNIP

Best regards,
Andrew Ballance