stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH] crypto: af_alg - Fix regression on empty requests
       [not found]         ` <20200626062948.GA25285@gondor.apana.org.au>
@ 2020-06-30  8:48           ` Naresh Kamboju
  2020-07-02  3:32             ` [v2 PATCH] " Herbert Xu
  0 siblings, 1 reply; 3+ messages in thread
From: Naresh Kamboju @ 2020-06-30  8:48 UTC (permalink / raw)
  To: Herbert Xu, Eric Biggers
  Cc: Luis Chamberlain, LTP List, open list, linux-security-module,
	keyrings, lkft-triage, Linux Crypto Mailing List, Jan Stancek,
	chrubis, Serge E. Hallyn, James Morris, Jarkko Sakkinen,
	David Howells, David S. Miller, Sachin Sant,
	Linux Next Mailing List, linuxppc-dev, linux- stable

On Fri, 26 Jun 2020 at 12:00, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Jun 23, 2020 at 10:02:17AM -0700, Eric Biggers wrote:
> >
> > The source code for the two failing AF_ALG tests is here:
> >
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypto/af_alg02.c
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypto/af_alg05.c
> >
> > They use read() and write(), not send() and recv().
> >
> > af_alg02 uses read() to read from a "salsa20" request socket without writing
> > anything to it.  It is expected that this returns 0, i.e. that behaves like
> > encrypting an empty message.

Since we are on this subject,
LTP af_alg02  test case fails on stable 4.9 and stable 4.4
This is not a regression because the test case has been failing from
the beginning.

Is this test case expected to fail on stable 4.9 and 4.4 ?
or any chance to fix this on these older branches ?

Test output:
af_alg02.c:52: BROK: Timed out while reading from request socket.

ref:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884917/suite/ltp-crypto-tests/test/af_alg02/history/
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884606/suite/ltp-crypto-tests/test/af_alg02/log

- Naresh

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [v2 PATCH] crypto: af_alg - Fix regression on empty requests
  2020-06-30  8:48           ` [PATCH] crypto: af_alg - Fix regression on empty requests Naresh Kamboju
@ 2020-07-02  3:32             ` Herbert Xu
  2020-07-03 13:35               ` Luis Chamberlain
  0 siblings, 1 reply; 3+ messages in thread
From: Herbert Xu @ 2020-07-02  3:32 UTC (permalink / raw)
  To: Naresh Kamboju
  Cc: Eric Biggers, Luis Chamberlain, LTP List, open list,
	linux-security-module, keyrings, lkft-triage,
	Linux Crypto Mailing List, Jan Stancek, chrubis, Serge E. Hallyn,
	James Morris, Jarkko Sakkinen, David Howells, David S. Miller,
	Sachin Sant, Linux Next Mailing List, linuxppc-dev,
	linux- stable

On Tue, Jun 30, 2020 at 02:18:11PM +0530, Naresh Kamboju wrote:
> 
> Since we are on this subject,
> LTP af_alg02  test case fails on stable 4.9 and stable 4.4
> This is not a regression because the test case has been failing from
> the beginning.
> 
> Is this test case expected to fail on stable 4.9 and 4.4 ?
> or any chance to fix this on these older branches ?
> 
> Test output:
> af_alg02.c:52: BROK: Timed out while reading from request socket.
> 
> ref:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884917/suite/ltp-crypto-tests/test/af_alg02/history/
> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884606/suite/ltp-crypto-tests/test/af_alg02/log

Actually this test really is broken.  Even though empty requests
are legal, they should never be done with no write(2) at all.
Because this fundamentally breaks the use of a blocking read(2)
to wait for more data.

Granted this has been broken since 2017 but I'm not going to
reintroduce this just because of a broken test case.

So please either remove af_alg02 or fix it by adding a control
message through sendmsg(2).

Thanks,

---8<---
Some user-space programs rely on crypto requests that have no
control metadata.  This broke when a check was added to require
the presence of control metadata with the ctx->init flag.

This patch fixes the regression by setting ctx->init as long as
one sendmsg(2) has been made, with or without a control message.

Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 9fcb91ea10c41..5882ed46f1adb 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -851,6 +851,7 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg, size_t size,
 		err = -EINVAL;
 		goto unlock;
 	}
+	ctx->init = true;
 
 	if (init) {
 		ctx->enc = enc;
@@ -858,7 +859,6 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg, size_t size,
 			memcpy(ctx->iv, con.iv->iv, ivsize);
 
 		ctx->aead_assoclen = con.aead_assoclen;
-		ctx->init = true;
 	}
 
 	while (size) {
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [v2 PATCH] crypto: af_alg - Fix regression on empty requests
  2020-07-02  3:32             ` [v2 PATCH] " Herbert Xu
@ 2020-07-03 13:35               ` Luis Chamberlain
  0 siblings, 0 replies; 3+ messages in thread
From: Luis Chamberlain @ 2020-07-03 13:35 UTC (permalink / raw)
  To: Herbert Xu
  Cc: Naresh Kamboju, Eric Biggers, LTP List, open list,
	linux-security-module, keyrings, lkft-triage,
	Linux Crypto Mailing List, Jan Stancek, chrubis, Serge E. Hallyn,
	James Morris, Jarkko Sakkinen, David Howells, David S. Miller,
	Sachin Sant, Linux Next Mailing List, linuxppc-dev,
	linux- stable

On Thu, Jul 02, 2020 at 01:32:21PM +1000, Herbert Xu wrote:
> On Tue, Jun 30, 2020 at 02:18:11PM +0530, Naresh Kamboju wrote:
> > 
> > Since we are on this subject,
> > LTP af_alg02  test case fails on stable 4.9 and stable 4.4
> > This is not a regression because the test case has been failing from
> > the beginning.
> > 
> > Is this test case expected to fail on stable 4.9 and 4.4 ?
> > or any chance to fix this on these older branches ?
> > 
> > Test output:
> > af_alg02.c:52: BROK: Timed out while reading from request socket.
> > 
> > ref:
> > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884917/suite/ltp-crypto-tests/test/af_alg02/history/
> > https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.228-191-g082e807235d7/testrun/2884606/suite/ltp-crypto-tests/test/af_alg02/log
> 
> Actually this test really is broken.

FWIW the patch "umh: fix processed error when UMH_WAIT_PROC is used" was
dropped from linux-next for now as it was missing checking for signals.
I'll be open coding iall checks for each UMH_WAIT_PROC callers next. Its
not clear if this was the issue with this test case, but figured I'd let
you know.

  Luis

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-07-03 13:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CA+G9fYvHFs5Yx8TnT6VavtfjMN8QLPuXg6us-dXVJqUUt68adA@mail.gmail.com>
     [not found] ` <20200622224920.GA4332@42.do-not-panic.com>
     [not found]   ` <CA+G9fYsXDZUspc5OyfqrGZn=k=2uRiGzWY_aPePK2C_kZ+dYGQ@mail.gmail.com>
     [not found]     ` <20200623064056.GA8121@gondor.apana.org.au>
     [not found]       ` <20200623170217.GB150582@gmail.com>
     [not found]         ` <20200626062948.GA25285@gondor.apana.org.au>
2020-06-30  8:48           ` [PATCH] crypto: af_alg - Fix regression on empty requests Naresh Kamboju
2020-07-02  3:32             ` [v2 PATCH] " Herbert Xu
2020-07-03 13:35               ` Luis Chamberlain

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).