stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Ryan Roberts <ryan.roberts@arm.com>,
	Yury Norov <yury.norov@gmail.com>,
	Sasha Levin <sashal@kernel.org>,
	mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org
Subject: [PATCH AUTOSEL 5.15 09/16] sched_getaffinity: don't assume 'cpumask_size()' is fully initialized
Date: Wed, 22 Mar 2023 16:01:13 -0400	[thread overview]
Message-ID: <20230322200121.1997157-9-sashal@kernel.org> (raw)
In-Reply-To: <20230322200121.1997157-1-sashal@kernel.org>

From: Linus Torvalds <torvalds@linux-foundation.org>

[ Upstream commit 6015b1aca1a233379625385feb01dd014aca60b5 ]

The getaffinity() system call uses 'cpumask_size()' to decide how big
the CPU mask is - so far so good.  It is indeed the allocation size of a
cpumask.

But the code also assumes that the whole allocation is initialized
without actually doing so itself.  That's wrong, because we might have
fixed-size allocations (making copying and clearing more efficient), but
not all of it is then necessarily used if 'nr_cpu_ids' is smaller.

Having checked other users of 'cpumask_size()', they all seem to be ok,
either using it purely for the allocation size, or explicitly zeroing
the cpumask before using the size in bytes to copy it.

See for example the ublk_ctrl_get_queue_affinity() function that uses
the proper 'zalloc_cpumask_var()' to make sure that the whole mask is
cleared, whether the storage is on the stack or if it was an external
allocation.

Fix this by just zeroing the allocation before using it.  Do the same
for the compat version of sched_getaffinity(), which had the same logic.

Also, for consistency, make sched_getaffinity() use 'cpumask_bits()' to
access the bits.  For a cpumask_var_t, it ends up being a pointer to the
same data either way, but it's just a good idea to treat it like you
would a 'cpumask_t'.  The compat case already did that.

Reported-by: Ryan Roberts <ryan.roberts@arm.com>
Link: https://lore.kernel.org/lkml/7d026744-6bd6-6827-0471-b5e8eae0be3f@arm.com/
Cc: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 kernel/compat.c     | 2 +-
 kernel/sched/core.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/compat.c b/kernel/compat.c
index 55551989d9da5..fb50f29d9b361 100644
--- a/kernel/compat.c
+++ b/kernel/compat.c
@@ -152,7 +152,7 @@ COMPAT_SYSCALL_DEFINE3(sched_getaffinity, compat_pid_t,  pid, unsigned int, len,
 	if (len & (sizeof(compat_ulong_t)-1))
 		return -EINVAL;
 
-	if (!alloc_cpumask_var(&mask, GFP_KERNEL))
+	if (!zalloc_cpumask_var(&mask, GFP_KERNEL))
 		return -ENOMEM;
 
 	ret = sched_getaffinity(pid, mask);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c1458fa8beb3e..79d959d047ce8 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -8182,14 +8182,14 @@ SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigned int, len,
 	if (len & (sizeof(unsigned long)-1))
 		return -EINVAL;
 
-	if (!alloc_cpumask_var(&mask, GFP_KERNEL))
+	if (!zalloc_cpumask_var(&mask, GFP_KERNEL))
 		return -ENOMEM;
 
 	ret = sched_getaffinity(pid, mask);
 	if (ret == 0) {
 		unsigned int retlen = min(len, cpumask_size());
 
-		if (copy_to_user(user_mask_ptr, mask, retlen))
+		if (copy_to_user(user_mask_ptr, cpumask_bits(mask), retlen))
 			ret = -EFAULT;
 		else
 			ret = retlen;
-- 
2.39.2


  parent reply	other threads:[~2023-03-22 20:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22 20:01 [PATCH AUTOSEL 5.15 01/16] xfrm: Zero padding when dumping algos and encap Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 02/16] ASoC: codecs: tx-macro: Fix for KASAN: slab-out-of-bounds Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 03/16] md: avoid signed overflow in slot_store() Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 04/16] x86/PVH: obtain VGA console info in Dom0 Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 05/16] net: hsr: Don't log netdev_err message on unknown prp dst node Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 06/16] ALSA: asihpi: check pao in control_message() Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 07/16] ALSA: hda/ca0132: fixup buffer overrun at tuning_ctl_set() Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 08/16] fbdev: tgafb: Fix potential divide by zero Sasha Levin
2023-03-22 20:01 ` Sasha Levin [this message]
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 10/16] fbdev: nvidia: " Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 11/16] fbdev: intelfb: " Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 12/16] fbdev: lxfb: " Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 13/16] fbdev: au1200fb: " Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 14/16] tools/power turbostat: Fix /dev/cpu_dma_latency warnings Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 15/16] tools/power turbostat: fix decoding of HWP_STATUS Sasha Levin
2023-03-22 20:01 ` [PATCH AUTOSEL 5.15 16/16] tracing: Fix wrong return in kprobe_event_gen_test.c Sasha Levin

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=20230322200121.1997157-9-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ryan.roberts@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vincent.guittot@linaro.org \
    --cc=yury.norov@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;
as well as URLs for NNTP newsgroup(s).