Netdev List
 help / color / mirror / Atom feed
From: Sabrina Dubroca <sd@queasysnail.net>
To: Steffen Klassert <steffen.klassert@secunet.com>,
	Zijing Yin <yzjaurora@gmail.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Ido Schimmel <idosch@nvidia.com>,
	Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH net v2] net: af_key: initialize alg_key_len for IPComp states
Date: Mon, 8 Jun 2026 18:03:42 +0200	[thread overview]
Message-ID: <aibn3tkGc3Iz1r5n@krikkit> (raw)
In-Reply-To: <20260608144453.3553219-1-yzjaurora@gmail.com>

note: fixes for IPsec should go to the "ipsec" tree, not net

2026-06-08, 07:44:41 -0700, Zijing Yin wrote:
> pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by
> allocating x->calg and copying only the algorithm name:
> 
> 	x->calg = kmalloc_obj(*x->calg);
> 	if (!x->calg) {
> 		err = -ENOMEM;
> 		goto out;
> 	}
> 	strcpy(x->calg->alg_name, a->name);
> 	x->props.calgo = sa->sadb_sa_encrypt;
> 
> Unlike the authentication (x->aalg) and encryption (x->ealg) branches of
> the same function, the compression branch never initializes
> calg->alg_key_len.  IPComp carries no key and the allocation only
> reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field
> is left containing uninitialized slab data.
> 
> calg->alg_key_len is later used as a length by xfrm_algo_clone() when an
> IPComp state is cloned during XFRM_MSG_MIGRATE:

The patch looks correct, but do we want to start fixing random bugs in
code that we're trying to get rid of and that nobody actually uses?

If we do, then:
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>

-- 
Sabrina

      reply	other threads:[~2026-06-08 16:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-08 14:44 [PATCH net v2] net: af_key: initialize alg_key_len for IPComp states Zijing Yin
2026-06-08 16:03 ` Sabrina Dubroca [this message]

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=aibn3tkGc3Iz1r5n@krikkit \
    --to=sd@queasysnail.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=yzjaurora@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox