linux-kernel - Re: Another regression in the af

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]

Message-ID: <yt9dsf9abhu3.fsf@linux.ibm.com>
Date:   Wed, 26 Jul 2023 21:20:20 +0200
From:   Sven Schnelle <svens@...ux.ibm.com>
To:     David Howells <dhowells@...hat.com>
Cc:     Ondrej Mosnáček <omosnacek@...il.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        regressions@...ts.linux.dev,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Harald Freudenberger <freude@...ux.vnet.ibm.com>
Subject: Re: Another regression in the af_alg series (s390x-specific)

David Howells <dhowells@...hat.com> writes:

> Well, I can reproduce it fairly easily.  It seems to be:
>
> 	static inline void scatterwalk_start(struct scatter_walk *walk,
> 					     struct scatterlist *sg)
> 	{
> 		walk->sg = sg;
> 		walk->offset = sg->offset;  <----
> 	}
>
> Presumably sg is rubbish.
>
> Dump of assembler code for function gcm_walk_start:
>    0x0000000000000038 <+0>:     jgnop   0x38 <gcm_walk_start>
>    0x000000000000003e <+6>:     xc      8(64,%r2),8(%r2)
>    0x0000000000000044 <+12>:    st      %r4,32(%r2)
>    0x0000000000000048 <+16>:    stg     %r3,0(%r2)
>    0x000000000000004e <+22>:    l       %r1,8(%r3)
>    0x0000000000000052 <+26>:    st      %r1,8(%r2)
>    0x0000000000000056 <+30>:    jg      0x56 <gcm_walk_start+30>
>
> I'm don't know much about s390x assembly, but I'm guessing %r2 has "walk" and
> %r3 has "sg".

Correct. I looked into this today, and it happens with c1abe6f570af
("crypto: af_alg: Use extract_iter_to_sg() to create scatterlists"),
but not with the commit before. It also only happens with
arch/s390/crypto/aes_s390.c, but not with a generic aes implementation.
I also see the s390 aes driver returning EBADMSG even when it's not
crashing the kernel, so i wonder wether it's another problem in some
error path.

I tried to understand the patch mentioned above, but i never worked with
the crypto API in recent years, so that would require some learning on
my side. Adding Harald, maybe he has some more insight.

> AS:0000000116d50007 R3:0000000000000024 
> Fault in home space mode while using kernel ASCE.
> Failing address: 0026070200000000 TEID: 0026070200000803
> Unable to handle kernel pointer dereference in virtual kernel address space
>
> Krnl GPRS: 000000000000000c 0000038000000310 00000380002a7938 0026070200000000
>            0000000000000000 0000000115593cb4 0000000000000000 0000000000000010
>            0000000100000000 000000017e984690 000000000000000c 0000000000000000
>            000003ffaf12cf98 0000000000000000 000003ff7fc536ba 00000380002a77e0
>
> I'm not sure what to make of the 0026070200000000.

Well, propbably just an arbitry value loaded from corrupted memory.