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

David Howells [off-list ref] 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.