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: <20260104100230.09abd1beaca2123d174022b2@linux-foundation.org>
Date: Sun, 4 Jan 2026 10:02:30 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Ryan Roberts <ryan.roberts@....com>
Cc: Alexander Potapenko <glider@...gle.com>, Marco Elver <elver@...gle.com>,
 Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v1] mm: kmsan: Fix poisoning of high-order non-compound
 pages

On Sun,  4 Jan 2026 13:43:47 +0000 Ryan Roberts <ryan.roberts@....com> wrote:

> kmsan_free_page() is called by the page allocator's free_pages_prepare()
> during page freeing. It's job is to poison all the memory covered by the
> page. It can be called with an order-0 page, a compound high-order page
> or a non-compound high-order page. But page_size() only works for
> order-0 and compound pages. For a non-compound high-order page it will
> incorrectly return PAGE_SIZE.
> 
> The implication is that the tail pages of a high-order non-compound page
> do not get poisoned at free, so any invalid access while they are free
> could go unnoticed. It looks like the pages will be poisoned again at
> allocaiton time, so that would bookend the window.
> 
> Fix this by using the order parameter to calculate the size.
> 
> Fixes: b073d7f8aee4 ("mm: kmsan: maintain KMSAN metadata for page operations")
> Cc: stable@...r.kernel.org
> Signed-off-by: Ryan Roberts <ryan.roberts@....com>
> ---
> 
> Hi,
> 
> I noticed this during code review, so perhaps I've just misunderstood the intent
> of the code.
>
> I don't have the means to compile and run on x86 with KMSAN enabled though, so
> punting this out hoping someone might be able to validate/test. I guess there is
> a small chance this could lead to KMSAN finding some new issues?

We'll see, I'll park this in mm-new to get it a little testing, see if
anything is shaken out.  If all looks good and if the KMSAN maintainers
are OK with it I'll later move the patch into mm-hotfixes for more
expedited upstreaming.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ