[PATCH] rust: firmware: return empty slice for zero-size firmware

[PATCH] rust: firmware: return empty slice for zero-size firmware

[Yuan Tan]

Firmware::data() builds a Rust slice with core::slice::from_raw_parts().
Unlike many C APIs, from_raw_parts() requires its pointer argument to be
non-NULL even when the length is zero.

The firmware loader can represent an empty firmware image with size == 0
and data == NULL. Passing that pointer to from_raw_parts() would be
undefined behavior.

Return an empty slice before constructing the raw slice. For non-zero
firmware sizes, the existing firmware API guarantee that data has size
bytes also means that the pointer is non-NULL.

Fixes: de6582833db0 ("rust: add firmware abstractions")
Cc: stable@vger.kernel.org
Reported-by: Priya Bala Govindasamy <pgovind2@uci.edu>
Reported-by: Dylan Zueck <dzueck@uci.edu>
Signed-off-by: Yuan Tan <ytan089@ucr.edu>
---
 rust/kernel/firmware.rs | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs
index 71168d8004e2..5e22a574a91e 100644
--- a/rust/kernel/firmware.rs
+++ b/rust/kernel/firmware.rs
@@ -106,10 +106,17 @@ pub fn size(&self) -> usize {
 
     /// Returns the requested firmware as `&[u8]`.
     pub fn data(&self) -> &[u8] {
+        let size = self.size();
+
+        if size == 0 {
+            return &[];
+        }
+
         // SAFETY: `self.as_raw()` is valid by the type invariant. Additionally,
         // `bindings::firmware` guarantees, if successfully requested, that
         // `bindings::firmware::data` has a size of `bindings::firmware::size` bytes.
-        unsafe { core::slice::from_raw_parts((*self.as_raw()).data, self.size()) }
+        // For non-zero `size`, this also means `bindings::firmware::data` is not NULL.
+        unsafe { core::slice::from_raw_parts((*self.as_raw()).data, size) }
     }
 }
 
-- 
2.43.2

Re: [PATCH] rust: firmware: return empty slice for zero-size firmware

[Onur Özkan]

On Thu, 04 Jun 2026 21:11:34 -0700
Yuan Tan <ytan089@ucr.edu> wrote:

> Firmware::data() builds a Rust slice with core::slice::from_raw_parts().
> Unlike many C APIs, from_raw_parts() requires its pointer argument to be
> non-NULL even when the length is zero.
> 
> The firmware loader can represent an empty firmware image with size == 0


I haven't checked in detail yet but "empty firmware image with size == 0"
sounds like an invalid image. Can such an image actually make it all the way
to Firmware::data()? I would be surprised if the loader accepted it.

Thanks,
Onur

> and data == NULL. Passing that pointer to from_raw_parts() would be
> undefined behavior.
> 
> Return an empty slice before constructing the raw slice. For non-zero
> firmware sizes, the existing firmware API guarantee that data has size
> bytes also means that the pointer is non-NULL.
> 
> Fixes: de6582833db0 ("rust: add firmware abstractions")
> Cc: stable@vger.kernel.org
> Reported-by: Priya Bala Govindasamy <pgovind2@uci.edu>
> Reported-by: Dylan Zueck <dzueck@uci.edu>
> Signed-off-by: Yuan Tan <ytan089@ucr.edu>
> ---
>  rust/kernel/firmware.rs | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/firmware.rs b/rust/kernel/firmware.rs
> index 71168d8004e2..5e22a574a91e 100644
> --- a/rust/kernel/firmware.rs
> +++ b/rust/kernel/firmware.rs
> @@ -106,10 +106,17 @@ pub fn size(&self) -> usize {
>  
>      /// Returns the requested firmware as `&[u8]`.
>      pub fn data(&self) -> &[u8] {
> +        let size = self.size();
> +
> +        if size == 0 {
> +            return &[];
> +        }
> +
>          // SAFETY: `self.as_raw()` is valid by the type invariant. Additionally,
>          // `bindings::firmware` guarantees, if successfully requested, that
>          // `bindings::firmware::data` has a size of `bindings::firmware::size` bytes.
> -        unsafe { core::slice::from_raw_parts((*self.as_raw()).data, self.size()) }
> +        // For non-zero `size`, this also means `bindings::firmware::data` is not NULL.
> +        unsafe { core::slice::from_raw_parts((*self.as_raw()).data, size) }
>      }
>  }
>  
> -- 
> 2.43.2
> 

Re: [PATCH] rust: firmware: return empty slice for zero-size firmware

[Gary Guo]

On Fri Jun 5, 2026 at 8:10 AM BST, Onur Özkan wrote:
> On Thu, 04 Jun 2026 21:11:34 -0700
> Yuan Tan <ytan089@ucr.edu> wrote:
>
>> Firmware::data() builds a Rust slice with core::slice::from_raw_parts().
>> Unlike many C APIs, from_raw_parts() requires its pointer argument to be
>> non-NULL even when the length is zero.
>> 
>> The firmware loader can represent an empty firmware image with size == 0
>
>
> I haven't checked in detail yet but "empty firmware image with size == 0"
> sounds like an invalid image. Can such an image actually make it all the way
> to Firmware::data()? I would be surprised if the loader accepted it.

`kernel_read_file` will return EINVAL if file is of zero size. But I think the
decompression path might produce this? The zstd code just does a

    out_buf = vzalloc(out_size);

which will trigger a WARN but still return NULL.

That said, I doubt any valid firmware will be just a compressed empty file.

Best,
Gary

Re: [PATCH] rust: firmware: return empty slice for zero-size firmware

[Onur Özkan]

On Fri, 05 Jun 2026 09:13:55 +0100
Gary Guo <gary@garyguo.net> wrote:

> On Fri Jun 5, 2026 at 8:10 AM BST, Onur Özkan wrote:
> > On Thu, 04 Jun 2026 21:11:34 -0700
> > Yuan Tan <ytan089@ucr.edu> wrote:
> >
> >> Firmware::data() builds a Rust slice with core::slice::from_raw_parts().
> >> Unlike many C APIs, from_raw_parts() requires its pointer argument to be
> >> non-NULL even when the length is zero.
> >> 
> >> The firmware loader can represent an empty firmware image with size == 0
> >
> >
> > I haven't checked in detail yet but "empty firmware image with size == 0"
> > sounds like an invalid image. Can such an image actually make it all the way
> > to Firmware::data()? I would be surprised if the loader accepted it.
> 
> `kernel_read_file` will return EINVAL if file is of zero size. But I think the
> decompression path might produce this? The zstd code just does a
> 
>     out_buf = vzalloc(out_size);
> 
> which will trigger a WARN but still return NULL.

On NULL, it immediately fails with ENOMEM:

	out_buf = vzalloc(out_size);
	if (!out_buf)
		return -ENOMEM;

Thanks,
Onur

> 
> That said, I doubt any valid firmware will be just a compressed empty file.
> 
> Best,
> Gary

Re: [PATCH] rust: firmware: return empty slice for zero-size firmware

[Gary Guo]

On Fri Jun 5, 2026 at 10:16 AM BST, Onur Özkan wrote:
> On Fri, 05 Jun 2026 09:13:55 +0100
> Gary Guo <gary@garyguo.net> wrote:
>
>> On Fri Jun 5, 2026 at 8:10 AM BST, Onur Özkan wrote:
>> > On Thu, 04 Jun 2026 21:11:34 -0700
>> > Yuan Tan <ytan089@ucr.edu> wrote:
>> >
>> >> Firmware::data() builds a Rust slice with core::slice::from_raw_parts().
>> >> Unlike many C APIs, from_raw_parts() requires its pointer argument to be
>> >> non-NULL even when the length is zero.
>> >> 
>> >> The firmware loader can represent an empty firmware image with size == 0
>> >
>> >
>> > I haven't checked in detail yet but "empty firmware image with size == 0"
>> > sounds like an invalid image. Can such an image actually make it all the way
>> > to Firmware::data()? I would be surprised if the loader accepted it.
>> 
>> `kernel_read_file` will return EINVAL if file is of zero size. But I think the
>> decompression path might produce this? The zstd code just does a
>> 
>>     out_buf = vzalloc(out_size);
>> 
>> which will trigger a WARN but still return NULL.
>
> On NULL, it immediately fails with ENOMEM:
>
> 	out_buf = vzalloc(out_size);
> 	if (!out_buf)
> 		return -ENOMEM;
>
> Thanks,
> Onur

Oh right. Arguably the wrong error code, but it does prevent the path from being
hit. xz decompression always grow at least 1 page and thus won't hit NULL case
as well.

So indeed under no paths we will have a sucessful `request_firmware` with
`buffer` is NULL.

Best,
Gary

Re: [PATCH] rust: firmware: return empty slice for zero-size firmware

[Miguel Ojeda]

On Fri, Jun 5, 2026 at 11:28 AM Gary Guo <gary@garyguo.net> wrote:
>
> Oh right. Arguably the wrong error code, but it does prevent the path from being
> hit. xz decompression always grow at least 1 page and thus won't hit NULL case
> as well.
>
> So indeed under no paths we will have a sucessful `request_firmware` with
> `buffer` is NULL.

If we are not expecting it in practice, then at least a
`debug_assert!` would be nice, or perhaps even making it an invariant?

Cheers,
Miguel

Re: [PATCH] rust: firmware: return empty slice for zero-size firmware

[Onur Özkan]

On Fri, 05 Jun 2026 13:15:32 +0200
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:

> On Fri, Jun 5, 2026 at 11:28 AM Gary Guo <gary@garyguo.net> wrote:
> >
> > Oh right. Arguably the wrong error code, but it does prevent the path from being
> > hit. xz decompression always grow at least 1 page and thus won't hit NULL case
> > as well.
> >
> > So indeed under no paths we will have a sucessful `request_firmware` with
> > `buffer` is NULL.
> 
> If we are not expecting it in practice, then at least a
> `debug_assert!` would be nice, or perhaps even making it an invariant?

I think `debug_assert!` would be nice.

Thanks,
Onur

> 
> Cheers,
> Miguel