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  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]
Date:   Thu, 22 Sep 2022 23:05:47 +0200
From:   Vlastimil Babka <>
To:     Kees Cook <>,
        Christian König <>
Cc:     Pekka Enberg <>, Feng Tang <>,
        David Rientjes <>,
        Joonsoo Kim <>,
        Andrew Morton <>,
        "David S. Miller" <>,
        Eric Dumazet <>,
        Jakub Kicinski <>,
        Paolo Abeni <>,
        Greg Kroah-Hartman <>,
        Nick Desaulniers <>,
        Alex Elder <>,
        Josef Bacik <>,
        David Sterba <>,
        Sumit Semwal <>,
        Jesse Brandeburg <>,
        Daniel Micay <>,
        Yonghong Song <>, Marco Elver <>,
        Miguel Ojeda <>,,,,,,,,,,,,,,,
        Hyeonggon Yoo <>,
        Feng Tang <>
Subject: Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup()

On 9/22/22 17:55, Kees Cook wrote:
> On Thu, Sep 22, 2022 at 09:10:56AM +0200, Christian König wrote:
>> Am 22.09.22 um 05:10 schrieb Kees Cook:
>> > Hi,
>> > 
>> > This series fixes up the cases where callers of ksize() use it to
>> > opportunistically grow their buffer sizes, which can run afoul of the
>> > __alloc_size hinting that CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE
>> > use to perform dynamic buffer bounds checking.
>> Good cleanup, but one question: What other use cases we have for ksize()
>> except the opportunistically growth of buffers?
> The remaining cases all seem to be using it as a "do we need to resize
> yet?" check, where they don't actually track the allocation size
> themselves and want to just depend on the slab cache to answer it. This
> is most clearly seen in the igp code:
> My "solution" there kind of side-steps it, and leaves ksize() as-is:
> The more correct solution would be to add per-v_idx size tracking,
> similar to the other changes I sent:
> I wonder if perhaps I should just migrate some of this code to using
> something like struct membuf.
>> Off hand I can't see any.
>> So when this patch set is about to clean up this use case it should probably
>> also take care to remove ksize() or at least limit it so that it won't be
>> used for this use case in the future.
> Yeah, my goal would be to eliminate ksize(), and it seems possible if
> other cases are satisfied with tracking their allocation sizes directly.

I think we could leave ksize() to determine the size without a need for
external tracking, but from now on forbid callers from using that hint to
overflow the allocation size they actually requested? Once we remove the
kasan/kfence hooks in ksize() that make the current kinds of usage possible,
we should be able to catch any offenders of the new semantics that would appear?

> -Kees

Powered by blists - more mailing lists