netdev - Re: [PATCH] net: tls: enable __GFP_ZERO upon tls

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 30 Jun 2023 01:15:36 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Jakub Kicinski <kuba@...nel.org>, Boris Pismenny <borisp@...dia.com>,
	John Fastabend <john.fastabend@...il.com>, glider@...gle.com,
	herbert@...dor.apana.org.au, linux-crypto@...r.kernel.org,
	syzkaller-bugs@...glegroups.com,
	syzbot <syzbot+828dfc12440b4f6f305d@...kaller.appspotmail.com>,
	Aviad Yehezkel <aviadye@...dia.com>,
	Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH] net: tls: enable __GFP_ZERO upon tls_init()

On Thu, Jun 29, 2023 at 07:15:21AM +0900, Tetsuo Handa wrote:
> On 2023/06/29 6:03, Jakub Kicinski wrote:
> > On Wed, 28 Jun 2023 22:48:01 +0900 Tetsuo Handa wrote:
> >> syzbot is reporting uninit-value at aes_encrypt(), for block cipher assumes
> >> that bytes to encrypt/decrypt is multiple of block size for that cipher but
> >> tls_alloc_encrypted_msg() is not initializing padding bytes when
> >> required_size is not multiple of block cipher's block size.
> > 
> > Sounds odd, so crypto layer reads beyond what we submitted as 
> > the buffer? I don't think the buffer needs to be aligned, so
> > the missing bits may well fall into a different (unmapped?) page.
> 
> Since passing __GFP_ZERO to skb_page_frag_refill() hides this problem,
> I think that crypto layer is reading up to block size when requested
> size is not multiple of block size.
> 
> > 
> > This needs more careful investigation. Always zeroing the input 
> > is just covering up the real issue.
> 
> Since block cipher needs to read up to block size, someone has to initialize
> padding bytes. I guess that crypto API caller is responsible for allocating
> and initializing padding bytes, otherwise such crypto API caller will fail to
> encrypt/decrypt last partial bytes which are not multiple of cipher's block
> size.
> 
> Which function in this report is responsible for initializing padding bytes?

According to the sample crash report from
https://syzkaller.appspot.com/bug?extid=828dfc12440b4f6f305d, the uninitialized
memory access happens while the TLS layer is doing an AES-CCM encryption
operation.  CCM supports arbitrarily-aligned additional authenticated data and
plaintext/ciphertext.  Also, an encryption with crypto_aead_encrypt() reads
exactly 'assoclen + cryptlen' bytes from the 'src' scatterlist; it's not
supposed to ever go past that, even if the data isn't "block aligned".

The "aead" API (include/crypto/aead.h) is still confusing and hard to use
correctly, though, mainly because of the weird scatterlist layout it expects
with the AAD and plaintext/ciphertext concatenated to each other.  I wouldn't be
surprised if the TLS layer is making some error.  What is the exact sequence of
crypto_aead_* calls that results in this issue?

- Eric