All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Abhishek Shah <abhishek.shah@columbia.edu>
Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	netdev@vger.kernel.org, pabeni@redhat.com,
	steffen.klassert@secunet.com, linux-kernel@vger.kernel.org,
	Gabriel Ryan <gabe@cs.columbia.edu>
Subject: Re: Race 1 in net/xfrm/xfrm_algo.c
Date: Fri, 22 Jul 2022 11:16:56 +0800	[thread overview]
Message-ID: <YtoWqEkKzvimzWS5@gondor.apana.org.au> (raw)
In-Reply-To: <CAEHB24-9hXY+TgQKxJB4bE9a9dFD9C+Lan+ShBwpvwaHVAGMFg@mail.gmail.com>

On Thu, Jul 21, 2022 at 12:03:04PM -0400, Abhishek Shah wrote:
> Dear Kernel Maintainers,
> 
> We found a race in net/xfrm/xfrm_algo.c. The function *xfrm_probe_algs* updates
> the availability field of items in a authentication algorithms list (
> *aalg_list* variable), but this update can occur simultaneously with
> another invocation of *xfrm_probe_algs*, leading to double writes and
> read/write consistency issues in scenarios where the *status* variable may
> vary across the concurrent invocations of the function. This behavior also
> occurs with another list with encryption algorithms (*ealg_list* variable)
> as well as with the *xfrm_find_algo* function. We thought this is
> undesirable given cryptographic logic errors often have security
> implications.
> 
> We provide more details below including the trace and reproducing
> test cases.

What inconsistency are you talking about? An algorithm can always
disappear even if it was available earlier.  Please state clearly
why this is actually a problem rather than relying on some automated
test whose results are useless without human interpretation.

Thanks,
-- 
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

       reply	other threads:[~2022-07-22  3:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAEHB24-9hXY+TgQKxJB4bE9a9dFD9C+Lan+ShBwpvwaHVAGMFg@mail.gmail.com>
2022-07-22  3:16 ` Herbert Xu [this message]
     [not found]   ` <CAEHB249ygptvp9wpynMF7zZ2Kcet0+bwLVuVg5UReZHOU1+8HA@mail.gmail.com>
2022-07-29  2:30     ` Race 1 in net/xfrm/xfrm_algo.c Herbert Xu
2022-08-04 10:03       ` [PATCH] af_key: Do not call xfrm_probe_algs in parallel Herbert Xu
2022-08-09  5:47         ` Steffen Klassert
2022-08-22 16:19         ` Gabriel Ryan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YtoWqEkKzvimzWS5@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=abhishek.shah@columbia.edu \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gabe@cs.columbia.edu \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.