[PATCH net] kcm: fix data race in /proc/net/kcm reader vs kcm_unattach

kcm_format_psock() reads strparser state (strp.stats.*, strp.stopped,
strp.paused, strp.need_bytes, ready_rx_msg) while only holding
mux->lock. Those fields are protected by mux->rx_lock and are mutated
concurrently by kcm_unattach() under rx_lock only.

The reader is reachable by any unprivileged local user with access to
a network namespace (CLONE_NEWNET in a user namespace is enough, since
/proc/net/kcm is 0444 and per-netns). The writer is triggered by
ordinary KCM socket teardown (SIOCKCMUNATTACH or close).

Currently the race is a torn read of strparser state exposed to
userspace. The ready_rx_msg pointer is only tested as a boolean and
not dereferenced, so this is an info-leak / instability bug rather
than a use-after-free. The lock-coverage mismatch is a latent hazard.

Fix: in kcm_format_mux(), take mux->rx_lock in addition to mux->lock
around the psock loop, honoring the existing lock order
(mux->lock -> mux->rx_lock is already used elsewhere in kcmsock.c).

Reported-by: Maksim Solodovnikov Novikava <redacted>
Signed-off-by: Maksim Solodovnikov Novikava <redacted>

From adfd837eba0d064f84455adbb90010d8ab31a0c9 Mon Sep 17 00:00:00 2001
From: Maksim Solodovnikov Novikava <redacted>
Date: Wed, 23 Sep 2026 22:40:38 +0200
Subject: [PATCH] kcm: fix data race in /proc/net/kcm reader vs kcm_unattach

kcm_format_psock() reads strparser state (strp.stats.*, strp.stopped,
strp.paused, strp.need_bytes, ready_rx_msg) while only holding
mux->lock. Those fields are protected by mux->rx_lock and are mutated
concurrently by kcm_unattach() under rx_lock only.

The reader is reachable by any unprivileged local user with access to
a network namespace (CLONE_NEWNET in a user namespace is enough, since
/proc/net/kcm is 0444 and per-netns). The writer is triggered by
ordinary KCM socket teardown (SIOCKCMUNATTACH or close).

Currently the race is a torn read of strparser state exposed to
userspace. The ready_rx_msg pointer is only tested as a boolean and
not dereferenced, so this is an info-leak / instability bug rather
than a use-after-free. The lock-coverage mismatch is a latent hazard.

Fix: in kcm_format_mux(), take mux->rx_lock in addition to mux->lock
around the psock loop, honoring the existing lock order
(mux->lock -> mux->rx_lock is already used elsewhere in kcmsock.c).
---
 net/kcm/kcmproc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/kcm/kcmproc.c b/net/kcm/kcmproc.c
index 25c1007f1..cf1516b4a 100644
--- a/net/kcm/kcmproc.c
+++ b/net/kcm/kcmproc.c

@@ -210,10 +210,12 @@ kcm_format_mux(struct kcm_mux *mux, loff_t idx,

struct seq_file *seq)
  i++;
  }
  i = 0;
+ spin_lock_bh(&mux->rx_lock);
  list_for_each_entry(psock, &mux->psocks, psock_list) {
  kcm_format_psock(psock, seq, i, &len);
  i++;
  }
+ spin_unlock_bh(&mux->rx_lock);
  spin_unlock_bh(&mux->lock);
 }

--
2.53.0