From: sashiko-bot@kernel.org
To: "Eric Biggers" <ebiggers@kernel.org>
Cc: "David Howells" <dhowells@redhat.com>,
"Marc Dionne" <marc.dionne@auristor.com>,
linux-crypto@vger.kernel.org,
"David S . Miller" <davem@davemloft.net>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>
Subject: Re: [PATCH net-next 3/5] net/rxrpc: Reimplement DES-PCBC using DES library
Date: Fri, 30 Oct 2026 04:53:36 +0000 [thread overview]
Message-ID: <sashiko-outbox-190325@kernel.org> (raw)
In-Reply-To: <20260428024400.123337-4-ebiggers@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Weak DES keys will now be rejected when loading a server key, whereas previously they were accepted.
--
commit c24ad4e831d157713b86ce93d80475105c2362d5
Author: Eric Biggers <ebiggers@kernel.org>
net/rxrpc: Reimplement DES-PCBC using DES library
This commit reimplements the obsolete PCBC mode on top of the DES library
specifically for rxrpc, replacing its use of the crypto API "pcbc(des)"
template. This allows removing PCBC support from the generic crypto API.
> diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
> index 3c9e7f636b42..4e04625f40eb 100644
> --- a/net/rxrpc/rxkad.c
> +++ b/net/rxrpc/rxkad.c
[ ... ]
> @@ -52,40 +54,41 @@ static void rxkad_prime_packet_security(struct rxrpc_connection *conn,
> */
> static int rxkad_preparse_server_key(struct key_preparsed_payload *prep)
> {
[ ... ]
> - if (crypto_skcipher_setkey(ci, prep->data, 8) < 0)
> - BUG();
> + err = des_expand_key(des_key, prep->data, 8);
> + if (err) {
> + kfree_sensitive(des_key);
> + _leave(" = %d", err);
> + return err;
> + }
Does this introduce an unintended behavior change regarding weak DES keys?
The old code used crypto_skcipher_setkey(), which in the generic DES
implementation suppresses the -ENOKEY error and returns 0 (success) unless
CRYPTO_TFM_REQ_FORBID_WEAK_KEYS is explicitly set. The RxRPC code did not
set this flag, meaning weak DES keys were silently accepted.
By calling des_expand_key() directly, which unconditionally returns -ENOKEY
for weak keys, rxkad_preparse_server_key() will now fail and reject these
keys instead of succeeding.
While weak keys shouldn't be used, could this undocumented change break
backward compatibility for existing userspace configurations or test
environments relying on fixed weak keys?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260428024400.123337-1-ebiggers@kernel.org?part=3
next prev parent reply other threads:[~2026-10-30 4:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 2:43 [PATCH net-next 0/5] Consolidate FCrypt and PCBC code into net/rxrpc/ Eric Biggers
2026-04-28 2:43 ` [PATCH net-next 1/5] net/rxrpc: Add local FCrypt-PCBC implementation Eric Biggers
2026-04-28 6:24 ` David Howells
2026-04-28 6:33 ` David Howells
2026-10-30 4:53 ` sashiko-bot
2026-10-30 18:13 ` Eric Biggers
2026-04-28 2:43 ` [PATCH net-next 2/5] net/rxrpc: Use " Eric Biggers
2026-05-08 18:02 ` David Howells
2026-05-08 18:23 ` Eric Biggers
2026-05-08 18:56 ` David Howells
2026-05-15 20:14 ` Eric Biggers
2026-05-15 20:58 ` David Howells
2026-10-30 4:53 ` sashiko-bot
2026-10-30 18:17 ` Eric Biggers
2026-04-28 2:43 ` [PATCH net-next 3/5] net/rxrpc: Reimplement DES-PCBC using DES library Eric Biggers
2026-10-30 4:53 ` sashiko-bot [this message]
2026-10-30 18:20 ` Eric Biggers
2026-04-28 2:43 ` [PATCH net-next 4/5] crypto: fcrypt - Remove support for FCrypt block cipher Eric Biggers
2026-04-28 10:03 ` Geert Uytterhoeven
2026-04-28 2:43 ` [PATCH net-next 5/5] crypto: pcbc - Remove support for PCBC mode Eric Biggers
2026-04-28 10:05 ` Geert Uytterhoeven
2026-04-28 7:53 ` [PATCH net-next 0/5] Consolidate FCrypt and PCBC code into net/rxrpc/ David Howells
2026-04-28 17:15 ` Marc Dionne
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=sashiko-outbox-190325@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=marc.dionne@auristor.com \
--cc=pabeni@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.