mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Ren Wei <n05ec@lzu.edu.cn>
Cc: linux-kernel@vger.kernel.org, david@kernel.org, arnd@arndb.de,
	ljs@kernel.org, kees@kernel.org,
	schuster.simon@siemens-energy.com, yuantan098@gmail.com,
	yifanwucs@gmail.com, tomapufckgml@gmail.com, bird@lzu.edu.cn,
	caoruide123@gmail.com, enjou1224z@gmail.com,
	Manfred Spraul <manfred@colorfullife.com>,
	Davidlohr Bueso <dave@stgolabs.net>
Subject: Re: [PATCH 1/1] ipc: sem: fix used_sems overflow in newary()
Date: Sat, 31 Oct 2026 20:37:26 -0700	[thread overview]
Message-ID: <20261031203726.2dca9645bd13ac9c18248380@linux-foundation.org> (raw)
In-Reply-To: <849fb1fdecd1cc241fd5b032602dbffa90f9dd93.1778477179.git.caoruide123@gmail.com>

> On Mon, 11 May 2026 18:42:53 +0800 Ren Wei <n05ec@lzu.edu.cn> wrote:

Slight delay, sorry!

> From: Ruide Cao <caoruide123@gmail.com>
> 
> newary() checks namespace-wide semaphore usage before creating a new
> array, but the current accounting uses a plain signed addition.
> 
> If the accumulated semaphore count overflows, the limit check can fail
> open and allow allocations past sc_semmns, breaking namespace semaphore
> resource enforcement and potentially leading to resource exhaustion.
> 
> Fix this by using check_add_overflow() before comparing the new total
> against sc_semmns, and reject overflow the same way as a true limit
> exceed.

LLM review tells me

: The fix looks correct. The existing writer lock covers the check and
: the later used_sems increment, so that increment needs no further
: change.

and

: Please qualify the changelog. Default SEMMNS and SEMMSL cannot trigger
: this overflow. It requires raised limits and substantial existing
: allocations: sem_alloc() separately bounds each array's size, so one
: enormous request isn't sufficient to demonstrate a successful bypass.
:
: With sufficient memory, semget() can then succeed instead of returning
: ENOSPC, exceed the namespace quota and wrap the semaphore usage reported
: by SEM_INFO negative. Additional allocations can increase memory
: pressure.

So I propose this changelog.  Please check:

: newary() checks the namespace-wide semaphore limit using a signed
: addition of used_sems and nsems. If that addition overflows, the
: comparison can fail to reject a request which exceeds sc_semmns.
: 
: The default semaphore limits cannot trigger this overflow. It requires
: raised limits and substantial existing allocations. sem_alloc()
: separately bounds each array's allocation size, so a single enormous
: request is insufficient to demonstrate a successful quota bypass.
: 
: With enough memory, semget() can succeed instead of returning ENOSPC,
: allowing allocations beyond the namespace semaphore quota and increasing
: memory pressure. The wrapped used_sems count can also cause SEM_INFO to
: report a negative semaphore usage count.
: 
: Use check_add_overflow() before comparing the new total against
: sc_semmns, rejecting overflow with ENOSPC. The existing writer lock
: covers both the check and the later accounting update.


> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Signed-off-by: Ruide Cao <caoruide123@gmail.com>
> Tested-by: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
>  ipc/sem.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/ipc/sem.c b/ipc/sem.c
> index 6cdf862b1f5c..00c45de33c46 100644
> --- a/ipc/sem.c
> +++ b/ipc/sem.c
> @@ -535,11 +535,13 @@ static int newary(struct ipc_namespace *ns, struct ipc_params *params)
>  	key_t key = params->key;
>  	int nsems = params->u.nsems;
>  	int semflg = params->flg;
> +	int total_sems;
>  	int i;
>  
>  	if (!nsems)
>  		return -EINVAL;
> -	if (ns->used_sems + nsems > ns->sc_semmns)
> +	if (check_add_overflow(ns->used_sems, nsems, &total_sems) ||
> +	    total_sems > ns->sc_semmns)
>  		return -ENOSPC;
>  
>  	sma = sem_alloc(nsems);
> -- 
> 2.34.1
> 

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

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1778477179.git.caoruide123@gmail.com>
2026-05-11 10:42 ` Ren Wei
2026-11-01  3:37   ` Andrew Morton [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=20261031203726.2dca9645bd13ac9c18248380@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bird@lzu.edu.cn \
    --cc=caoruide123@gmail.com \
    --cc=dave@stgolabs.net \
    --cc=david@kernel.org \
    --cc=enjou1224z@gmail.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=n05ec@lzu.edu.cn \
    --cc=schuster.simon@siemens-energy.com \
    --cc=tomapufckgml@gmail.com \
    --cc=yifanwucs@gmail.com \
    --cc=yuantan098@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

all inboxes | Powered by JetHome®