netdev - Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

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]

Date:   Fri, 14 Oct 2016 11:10:48 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        "linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Wireless List <linux-wireless@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jouni Malinen <j@...fi>
Subject: Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Fri, 2016-10-14 at 10:05 +0100, Ard Biesheuvel wrote:
> 
> Indeed. And the decrypt path does the same for auth_tag[].

Hadn't gotten that far, due to the BUG_ON() in CONFIG_DEBUG_SG in the
encrypt path :)

> But that still means there are two separate problems here, one which
> affects the WPA code, and one that only affects the generic CCM
> chaining mode (but not the accelerated arm64 implementation)

Yes. The generic CCM chaining still doesn't typically have a request on
the stack though. In fact, ESP (net/ipv4/esp4.c) for example will do
temporary allocations with kmalloc for every frame, it seems.

> Unsurprisingly, I would strongly prefer those to be fixed properly
> rather than backing out my patch, but I'm happy to help out whichever
> solution we reach consensus on.

Yeah, obviously, it would be good to use the accelerated versions after
all.

> I will check whether this removes the issue when not using
> crypto/ccm.ko

Ok. I think we can probably live with having those 48 bytes in per-CPU
buffers, but I suppose we don't really want to have ~500.

johannes