Re: Another regression in the af_alg series (s390x-specific)

[Sven Schnelle]

David Howells <dhowells@xxxxxxxxxx> 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.