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]
Date:   Thu, 12 Jul 2018 23:15:51 +0200
From:   Arnd Bergmann <>
To:     Kees Cook <>
Cc:     Herbert Xu <>,
        "Gustavo A. R. Silva" <>,
        Eric Biggers <>,
        Alasdair Kergon <>,
        Giovanni Cabiddu <>,
        Lars Persson <>,
        Mike Snitzer <>,
        Rabin Vincent <>,
        Tim Chen <>,
        "David S. Miller" <>,
        Masahiro Yamada <>,
        Linux Kernel Mailing List <>,
        David Howells <>
Subject: Re: [PATCH v4 13/14] rxrpc: Prepare to remove VLA usage for SKCIPHER_REQUEST_ON_STACK

On Thu, Jul 12, 2018 at 10:30 PM, Kees Cook <> wrote:
> On Thu, Jul 12, 2018 at 1:23 PM, Kees Cook <> wrote:
>> On Thu, Jul 12, 2018 at 8:11 AM, Arnd Bergmann <> wrote:
>>> On Wed, Jul 11, 2018 at 10:36 PM, Kees Cook <> wrote:
>>>> Two uses of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
>>>> (when less than 2048) once the VLA is no longer hidden from the check:
>>>> net/rxrpc/rxkad.c:398:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>> net/rxrpc/rxkad.c:242:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>>>> This bumps the affected objects by 20% to silence the warnings while
>>>> still providing coverage is anything grows even more.
>>>> Signed-off-by: Kees Cook <>
>>> (adding David Howells to cc)
>>> I don't think these are in a fast path, it should be possible to just use
>>> skcipher_alloc_req() instead of SKCIPHER_REQUEST_ON_STACK() here.
>>> From what I can tell, neither of the two are called in atomic context, so
>>> you should be able to use a GFP_KERNEL allocation.
>> Sure, I can do that instead.
> Actually, I think this can actually be adjusted to just re-use the
> stack allocation, since rxkad_verify_packet() finishes one before
> doing another in rxkad_verify_packet_1():

That looks very nice, yes. The same thing is needed in
rxkad_secure_packet(), right?


Powered by blists - more mailing lists