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]
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ