Re: [PATCH v4 3/5] gpu: nova-core: return non-WPR heap size as u64 from HALs

[email protected] Tue, 04 Aug 2026 05:51:07 +0000
Newsgroups org.freedesktop.lists.dri-devel
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:

Pre-existing issues:
- [High] Unchecked subtractions during framebuffer layout calculation can u=
nderflow if the hardware reports a small framebuffer size, causing a kernel=
 panic or out-of-bounds memory calculations.
--

--- Patch [3]: [PATCH v4 3/5] gpu: nova-core: return non-WPR heap size as u=
64 from HALs ---
commit cfb0bee1c128905c124d8b00afa2860ab971ac23
Author: Eliot Courtney <[email protected]>

gpu: nova-core: return non-WPR heap size as u64 from HALs

This patch updates the HALs to return the non-WPR heap size as a u64 to avo=
id
an immediate cast.

> diff --git a/drivers/gpu/nova-core/fb.rs b/drivers/gpu/nova-core/fb.rs
> index 4a1be29cf5fbd..86d2bdaab7f95 100644
> --- a/drivers/gpu/nova-core/fb.rs
> +++ b/drivers/gpu/nova-core/fb.rs
> @@ -271,7 +271,7 @@ pub(crate) fn new(
>          };
> =20
>          let non_wpr_heap =3D {
> -            let non_wpr_heap_size =3D u64::from(hal.non_wpr_heap_size());
> +            let non_wpr_heap_size =3D hal.non_wpr_heap_size();
>              FbRange(wpr2.start - non_wpr_heap_size..wpr2.start)

[Severity: High]
This isn't a bug introduced by this patch, but can this subtraction underfl=
ow if
the hardware reports an unexpectedly small framebuffer size?

Looking at FbLayout::new() in drivers/gpu/nova-core/fb.rs, there are multip=
le
places where sizes are subtracted from addresses without using checked_sub(=
),
such as:

    let base =3D fb.end - NV_PRAMIN_SIZE;
    ...
    let frts_base =3D vga_workspace.start.align_down(FRTS_DOWN_ALIGN) - frt=
s_size;
    ...
    let bootloader_base =3D (frts.start - bootloader_size).align_down(BOOTL=
OADER_DOWN_ALIGN);
    ...
    let elf_addr =3D (boot.start - elf_size).align_down(ELF_DOWN_ALIGN);
    ...
    let wpr2_addr =3D (wpr2_heap.start - u64::from_safe_cast(size_of::<gsp:=
:GspFwWprMeta>()))

Could these calculations trigger a kernel panic (with overflow checks enabl=
ed) or
result in out-of-bounds memory calculations if a small hardware-provided si=
ze is
used during initialization?

>          };
>

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260804-blackwell-=
[email protected]?part=3D3