All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jiayuan Chen" <jiayuan.chen@linux.dev>
Cc: linux-security-module@vger.kernel.org, mptcp@lists.linux.dev,
	linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>
Subject: Re: [PATCH net-next 05/14] calipso: annotate data-races around cache sysctls
Date: Tue, 10 Nov 2026 03:01:25 +0000	[thread overview]
Message-ID: <sashiko-outbox-206078@kernel.org> (raw)
In-Reply-To: <20261109025425.328445-6-jiayuan.chen@linux.dev>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] calipso: double READ_ONCE() of bucketsize in
  calipso_cache_add() causes TOCTOU
- [Low] calipso: missing Fixes trailer for commit 4fee5242bf41 in commit
  message
--

commit 430c1b1d214e9e8a15979062b88b1428916c12ef
Author: Jiayuan Chen <jiayuan.chen@linux.dev>

> calipso: annotate data-races around cache sysctls
> 
> calipso_cache_enabled and calipso_cache_bucketsize are read without any
> lock while their sysctl handlers update them with WRITE_ONCE(). Add
> READ_ONCE() to the readers.
> 
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>

[Severity: Low]
Should this include a Fixes tag for the commit that introduced the
unannotated sysctl reads?

  Fixes: 4fee5242bf41 ("calipso: Add a label cache.")

> diff --git a/net/ipv6/calipso.c b/net/ipv6/calipso.c
> index e399a42e30839..5e63212b60163 100644
> --- a/net/ipv6/calipso.c
> +++ b/net/ipv6/calipso.c

[ ... ]

> @@ -269,7 +269,7 @@ static int calipso_cache_add(const unsigned char *calipso_ptr,
>  	struct calipso_map_cache_entry *old_entry = NULL;
>  	u32 calipso_ptr_len;
>  
> -	if (!calipso_cache_enabled || calipso_cache_bucketsize <= 0)
> +	if (!READ_ONCE(calipso_cache_enabled) || READ_ONCE(calipso_cache_bucketsize) <= 0)
>  		return 0;
>  
>  	calipso_ptr_len = calipso_ptr[1];
> @@ -289,7 +289,7 @@ static int calipso_cache_add(const unsigned char *calipso_ptr,
>  
>  	bkt = entry->hash & (CALIPSO_CACHE_BUCKETS - 1);
>  	spin_lock_bh(&calipso_cache[bkt].lock);
> -	if (calipso_cache[bkt].size < calipso_cache_bucketsize) {
> +	if (calipso_cache[bkt].size < READ_ONCE(calipso_cache_bucketsize)) {
>  		list_add(&entry->list, &calipso_cache[bkt].list);
>  		calipso_cache[bkt].size += 1;
>  	} else {

[Severity: Medium]
Can reloading calipso_cache_bucketsize with a second READ_ONCE() corrupt
calipso_cache[bkt].list when the sysctl changes concurrently?

net/ipv6/calipso.c:calipso_cache_add() {
	...
	} else {
		old_entry = list_entry(calipso_cache[bkt].list.prev,
				       struct calipso_map_cache_entry, list);
		list_del(&old_entry->list);
		list_add(&entry->list, &calipso_cache[bkt].list);
		calipso_cache_entry_free(old_entry);
	}
	...
}

The else branch assumes the bucket list is non-empty because
calipso_cache_bucketsize was checked to be positive at function entry.
With two separate READ_ONCE() calls, a concurrent sysctl write can change
calipso_cache_bucketsize between them while calipso_cache[bkt].size is 0:

CPU0                                    CPU1
calipso_cache_add()
  READ_ONCE(calipso_cache_bucketsize)
    -> > 0
                                        proc_dointvec()
                                          WRITE_ONCE(calipso_cache_bucketsize, 0)
  spin_lock_bh(&calipso_cache[bkt].lock)
  calipso_cache[bkt].size <
    READ_ONCE(calipso_cache_bucketsize)
    -> 0 < 0 (false)
  old_entry = list_entry(...)
  list_del(&old_entry->list)
  calipso_cache_entry_free(old_entry)   <-- frees list head as entry

When calipso_cache[bkt].size is 0 and the second READ_ONCE() observes 0,
the else branch unlinks the empty list head and passes an interior pointer
of calipso_cache to calipso_cache_entry_free().  If the second READ_ONCE()
observes a negative value, comparing u32 calipso_cache[bkt].size against a
negative int promotes it to a large unsigned value and bypasses the bucket
size limit.

Snapshotting READ_ONCE(calipso_cache_bucketsize) into a local int variable
once and reusing it in both checks, as cipso_v4_cache_add() does in
dd44f04b9214 ("cipso: Fix data-races around sysctl."), avoids the second
load.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109025425.328445-1-jiayuan.chen@linux.dev?part=5

  reply	other threads:[~2026-11-10  3:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  2:51 [PATCH net-next 00/14] net: annotate data-races around sysctl knobs Jiayuan Chen
2026-11-09  2:52 ` [PATCH net-next 01/14] ipv4: annotate data-races around ip_rt_* sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  2:52 ` [PATCH net-next 02/14] inet: frags: annotate data-races around fqdir->timeout and fqdir->max_dist Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-09  2:52 ` [PATCH net-next 03/14] ipv6: annotate data-races around addrconf sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-09  2:52 ` [PATCH net-next 04/14] ipv6: annotate data-races around icmpv6 reply sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-09  2:52 ` [PATCH net-next 05/14] calipso: annotate data-races around cache sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot [this message]
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  2:52 ` [PATCH net-next 06/14] sctp: annotate data-races around sctp sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  2:52 ` [PATCH net-next 07/14] mptcp: annotate data-races around pernet sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-10 11:28   ` Matthieu Baerts
2026-11-09  2:52 ` [PATCH net-next 08/14] rds: annotate data-races around core rds sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-09  2:52 ` [PATCH net-next 09/14] netfilter: conntrack: annotate data-races around conntrack sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-09  2:52 ` [PATCH net-next 10/14] netfilter: bridge: annotate data-races around br_netfilter and nf_log sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  2:52 ` [PATCH net-next 11/14] ipvs: annotate data-races around lblc_expiration and lblcr_expiration Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-09  2:52 ` [PATCH net-next 12/14] net/smc: annotate data-races around smc sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-12  4:54   ` Dust Li
2026-11-09  2:52 ` [PATCH net-next 13/14] netfilter: conntrack: annotate data-races around timeout and tcp sysctls Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-09  2:52 ` [PATCH net-next 14/14] netfilter: cttimeout: annotate data-races around the default timeouts Jiayuan Chen
2026-11-10  3:01   ` sashiko-bot
2026-11-10  5:53   ` netdev-bot+sashiko
2026-11-09  3:11 ` [PATCH net-next 00/14] net: annotate data-races around sysctl knobs Jason Xing
2026-11-09  3:33   ` Jiayuan Chen
2026-11-09  6:52     ` Jason Xing
2026-11-09  4:59 ` MPTCP CI

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-206078@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=jiayuan.chen@linux.dev \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mptcp@lists.linux.dev \
    --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.