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