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 08:55:19 -0700
From:   Kees Cook <>
To:     Christian König <>
Cc:     Vlastimil Babka <>,
        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 <>,,,,,,,,,,,,,,
Subject: Re: [PATCH 00/12] slab: Introduce kmalloc_size_roundup()

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.


Kees Cook

Powered by blists - more mailing lists