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: <Z_LGqgUhDrTmzj5r@gmail.com>
Date: Sun, 6 Apr 2025 20:23:38 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Myrrh Periwinkle <myrrhperiwinkle@...labs.xyz>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, Roberto Ricci <io@...icci.it>
Subject: Re: [PATCH v3] x86/e820: Fix handling of subpage regions when
 calculating nosave ranges


* Myrrh Periwinkle <myrrhperiwinkle@...labs.xyz> wrote:

> The current implementation of e820__register_nosave_regions suffers from
> multiple serious issues:
>  - The end of last region is tracked by PFN, causing it to find holes
>    that aren't there if two consecutive subpage regions are present
>  - The nosave PFN ranges derived from holes are rounded out (instead of
>    rounded in) which makes it inconsistent with how explicitly reserved
>    regions are handled
> 
> Fix this by:
>  - Treating reserved regions as if they were holes, to ensure consistent
>    handling (rounding out nosave PFN ranges is more correct as the
>    kernel does not use partial pages)
>  - Tracking the end of the last RAM region by address instead of pages
>    to detect holes more precisely
> 
> Cc: stable@...r.kernel.org
> Fixes: e5540f875404 ("x86/boot/e820: Consolidate 'struct e820_entry *entry' local variable names")

So why is this SHA1 indicated as the root cause? AFAICS that commit 
does nothing but cleanups, so it cannot cause such regressions.

Thanks,

	Ingo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ