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
>
prev parent 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®