From: Steffen Klassert <steffen.klassert@secunet.com>
To: David Miller <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Steffen Klassert <steffen.klassert@secunet.com>,
<netdev@vger.kernel.org>
Subject: [PATCH 03/14] xfrm: zero-initialise km_event in the replay-notify path
Date: Mon, 2 Nov 2026 10:04:01 +0000 [thread overview]
Message-ID: <20261102100451.2505200-4-steffen.klassert@secunet.com> (raw)
In-Reply-To: <20261102100451.2505200-1-steffen.klassert@secunet.com>
From: Shubham Antil <shubham@octane.security>
xfrm_replay_notify(), xfrm_replay_notify_bmp() and
xfrm_replay_notify_esn() declare a struct km_event on the stack and
initialise only its .event and .data.aevent fields, leaving .seq and
.portid uninitialised. build_aevent() then builds the XFRM_MSG_NEWAE
message with those fields:
nlmsg_put(skb, c->portid, c->seq, ...)
so the netlink header of a replay event carries uninitialised stack
values rather than defined ones. This was confirmed at runtime rather
than by inspection alone: the .seq and .portid carried in that header
hold values that nothing in the replay path assigns.
The request-driven paths set these header fields from the requester
(xfrm_get_ae() / xfrm_new_ae()); only the kernel-originated replay path
leaves them unset. Zero-initialise the event so the header fields are 0,
the correct value for a kernel-originated notification.
Fixes: f8cd54884e67 ("[IPSEC]: Sync series - core changes")
Reported-by: Giovanni Vignone <gio@octane.security>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Shubham Antil <shubham@octane.security>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_replay.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/xfrm/xfrm_replay.c b/net/xfrm/xfrm_replay.c
index dbdf8a39dffe..9394953247ab 100644
--- a/net/xfrm/xfrm_replay.c
+++ b/net/xfrm/xfrm_replay.c
@@ -40,7 +40,7 @@ static void xfrm_replay_notify_esn(struct xfrm_state *x, int event);
void xfrm_replay_notify(struct xfrm_state *x, int event)
{
- struct km_event c;
+ struct km_event c = {};
/* we send notify messages in case
* 1. we updated on of the sequence numbers, and the seqno difference
* is at least x->replay_maxdiff, in this case we also update the
@@ -304,7 +304,7 @@ static void xfrm_replay_advance_bmp(struct xfrm_state *x, __be32 net_seq)
static void xfrm_replay_notify_bmp(struct xfrm_state *x, int event)
{
- struct km_event c;
+ struct km_event c = {};
struct xfrm_replay_state_esn *replay_esn = x->replay_esn;
struct xfrm_replay_state_esn *preplay_esn = x->preplay_esn;
@@ -356,7 +356,7 @@ static void xfrm_replay_notify_bmp(struct xfrm_state *x, int event)
static void xfrm_replay_notify_esn(struct xfrm_state *x, int event)
{
u32 seq_diff, oseq_diff;
- struct km_event c;
+ struct km_event c = {};
struct xfrm_replay_state_esn *replay_esn = x->replay_esn;
struct xfrm_replay_state_esn *preplay_esn = x->preplay_esn;
--
2.53.0
next prev parent reply other threads:[~2026-11-02 8:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 10:03 [PATCH 0/14] pull request (net): ipsec 2026-11-02 Steffen Klassert
2026-11-02 10:03 ` [PATCH 01/14] xfrm: retry inexact policy lookup after node reinsertion Steffen Klassert
2026-11-02 8:09 ` netdev-bot+sinfo
2026-11-02 10:04 ` [PATCH 02/14] xfrm: interface: validate the IP header on xmit Steffen Klassert
2026-11-02 10:04 ` Steffen Klassert [this message]
2026-11-02 10:04 ` [PATCH 04/14] xfrm: espintcp: reorder operations within espintcp_init_sk Steffen Klassert
2026-11-02 10:04 ` [PATCH 05/14] xfrm: state: reject mark with bits outside its mask on add Steffen Klassert
2026-11-02 10:04 ` [PATCH 06/14] xfrm: state: reject mark with bits outside its mask on ALLOCSPI Steffen Klassert
2026-11-02 10:04 ` [PATCH 07/14] xfrm: policy: reject mark with bits outside its mask on add Steffen Klassert
2026-11-02 10:04 ` [PATCH 08/14] xfrm: state: exact mark/mask match for SPI-keyed control-plane SA lookups Steffen Klassert
2026-11-02 10:04 ` [PATCH 09/14] xfrm: fix use-after-free of migrated state in xfrm_do_migrate_state() Steffen Klassert
2026-11-02 10:04 ` [PATCH 10/14] xfrm: fix hw offload state leak on xfrm_do_migrate_state() error path Steffen Klassert
2026-11-02 10:04 ` [PATCH 11/14] xfrm: include mark in MIGRATE_STATE SA collision check Steffen Klassert
2026-11-02 10:04 ` [PATCH 12/14] xfrm: pass extack through to xfrm_init_replay() from xfrm_init_state() Steffen Klassert
2026-11-02 10:04 ` [PATCH 13/14] docs: xfrm: include mark in XFRM_MSG_MIGRATE_STATE EEXIST tuple Steffen Klassert
2026-11-02 10:04 ` [PATCH 14/14] xfrm4: use a full socket for local errors Steffen Klassert
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=20261102100451.2505200-4-steffen.klassert@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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