linux-kernel - Re: [PATCH v2 RFC 1/7] mm/kasan: implement kasan_poison

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: <CAG_fn=VL1j42TxEoWD8Z3jO0uvU0j1JNzPS3BfUXd5AGE-nDkw@mail.gmail.com>
Date: Fri, 5 Sep 2025 11:32:45 +0200
From: Alexander Potapenko <glider@...gle.com>
To: Ethan Graham <ethan.w.s.graham@...il.com>
Cc: ethangraham@...gle.com, andreyknvl@...il.com, brendan.higgins@...ux.dev, 
	davidgow@...gle.com, dvyukov@...gle.com, jannh@...gle.com, elver@...gle.com, 
	rmoar@...gle.com, shuah@...nel.org, tarasmadan@...gle.com, 
	kasan-dev@...glegroups.com, kunit-dev@...glegroups.com, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, dhowells@...hat.com, 
	lukas@...ner.de, ignat@...udflare.com, herbert@...dor.apana.org.au, 
	davem@...emloft.net, linux-crypto@...r.kernel.org
Subject: Re: [PATCH v2 RFC 1/7] mm/kasan: implement kasan_poison_range

On Fri, Sep 5, 2025 at 10:46 AM Ethan Graham <ethan.w.s.graham@...il.com> wrote:
>
> On Fri, Sep 5, 2025 at 10:33 AM Alexander Potapenko <glider@...gle.com> wrote:
> > > + * - The poisoning of the range only extends up to the last full granule before
> > > + *     the end of the range. Any remaining bytes in a final partial granule are
> > > + *     ignored.
> >
> > Maybe we should require that the end of the range is aligned, as we do
> > for e.g. kasan_unpoison()?
> > Are there cases in which we want to call it for non-aligned addresses?
>
> It's possible in the current KFuzzTest input format. For example you have
> an 8 byte struct with a pointer to a 35-byte string. This results in a payload:
> struct [0: 8), padding [8: 16), string: [16: 51), padding: [51: 59). The
> framework will poison the unaligned region [51, 59).
>
> We could enforce that the size of the payload (including all padding) is
> a multiple of KASAN_GRANULE_SIZE, thus resulting in padding [51, 64)
> at the end of the payload. It makes encoding a bit more complex, but it
> may be a good idea to push that complexity up to the user space encoder.

As discussed offline, it might be good to always require the userspace
to align every region on KASAN_GRANULE_SIZE or ARCH_KMALLOC_MINALIGN
(whichever is greater).
In that case, we won't break any implicit assumptions that the code
under test has about the memory buffers passed to it, and we also
won't need to care about poisoning a range which has both its ends
unaligned.
Because that required alignment will likely depend on the arch/kernel
config, we can expose it via debugfs to make the userspace tools' life
easier.