linux-stable.git/lib, branch v7.2.6

maple_tree: catch race in mas_alloc_cyclic()

2026-09-14T11:41:06+00:00

[ Upstream commit 35f1342e5b893a740eff2ef9ab337bfaa63ab76d ]

If mas_alloc_cyclic() is called during a low memory situation, it is
possible the lock may be dropped so reclaim can occur.  There is a window
where some other task may allocate the same id and cause the mas_insert()
to fail with -EEXIST.  In this scenario the function will return -EEXIST,
which is not expected.

Modifying the retry on mas_nomem() to re-search for a slot means that any
race with other writes will not matter as the lock will be held between
finding the index and writing the index.

Moving the flag logic avoids cases where the flag is modified on drop
lock/reacquire or when the write fails after clearing the flag.

No existing users are exposed to this issue.

Link: https://lore.kernel.org/20260821192627.4085470-13-liam@infradead.org
Fixes: 9b6713cc7522 ("maple_tree: Add mtree_alloc_cyclic()")
Signed-off-by: Liam R. Howlett (Oracle) 
Reported-by: Chris Mason 
Reviewed-by: Chuck Lever 
Cc: Boqun Feng 
Cc: Breno Leitao 
Cc: Ingo Molnar 
Cc: Jason Gunthorpe 
Cc: Joe Perches 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Waiman Long 
Cc: Will Deacon 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

lib/interval_tree: fix allocation warning messages

2026-09-14T11:40:58+00:00

[ Upstream commit d9c0fd5533fb23bc445bd581feb140e966195936 ]

WARN_ON_ONCE() takes a condition, not a message.  The string literals are
always true, so the warnings still trigger but the messages are never
printed.

Use WARN_ONCE(1, ...) instead to print the messages and keep the once-only
behavior.

Found with a Coccinelle script.  Clang's -Wstring-conversion also flags
such calls but is not enabled in kernel builds.

Link: https://lore.kernel.org/20260808123608.73613-1-kmehltretter@gmail.com
Fixes: 82114e45131f ("lib/interval_tree: add test case for interval_tree_iter_xxx() helpers")
Assisted-by: Claude:claude-fable-5 coccinelle
Signed-off-by: Karl Mehltretter 
Reviewed-by: Andrew Morton 
Reviewed-by: Wei Yang 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

lib/string: fix memchr_inv() for large ranges

2026-09-14T11:40:16+00:00

[ Upstream commit c04cffb8c51618538f0c05c478a931eb6e1a806b ]

memchr_inv() takes a size_t length but counts 8 byte words in an unsigned
int.  At 32GiB that count wraps, so the scan can quietly miss most of the
range.

Use size_t for the word count.

Link: https://lore.kernel.org/20260621121133.16460-1-include@grrlz.net
Fixes: 798248206b59 ("lib/string.c: introduce memchr_inv()")
Signed-off-by: Bradley Morgan 
Cc: Akinbou Mita 
Cc: Andy Shevchenko 
Cc: Christoph Lameer 
Cc: Joern Engel 
Cc: Kees Cook 
Cc: Pekka Enberg 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

lib/test_hmm: fail dmirror_fault() when the mirrored mm is gone

2026-09-14T11:40:00+00:00

[ Upstream commit 6a8024511ddf4877435c34fb3d6028aa8e590649 ]

dmirror_fault() is called from the dmirror_read() and dmirror_write()
retry loops after dmirror_do_read() or dmirror_do_write() finds a missing
device page table entry.

If the mirrored mm has already exited, mmget_not_zero() fails.  The
current code returns 0 in that case, which tells the caller that faulting
succeeded even though no page was faulted and no device page table entry
was installed.  The caller then retries the same address, hits -ENOENT
again, and can loop forever without making progress.

Return -EFAULT instead, so the ioctl fails when the mirrored mm is no
longer faultable.

Link: https://lore.kernel.org/178294308408.327222.3319445682023999403.stgit@skinsburskii
Fixes: b2ef9f5a5cb37 ("mm/hmm/test: add selftest driver for HMM")
Signed-off-by: Stanislav Kinsburskii 
Cc: Jason Gunthorpe 
Cc: Leon Romanovsky 
Cc: Ralph Campbell 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

bitmap: Properly initialise destination bitmap for scatter & gather test

2026-09-14T11:39:45+00:00

[ Upstream commit 36f78b0dfa7df4892ba067ccf00d95a4513b4935 ]

Erhard reports failure of bitmap tests on powerpc:

  test_bitmap: loaded.
  test_bitmap: [lib/test_bitmap.c:397] bitmaps contents differ: expected "1,3-4,9", got "1,3-4,9,65-71,73-79,81-87,89-95,97-99"
  test_bitmap: parselist('0-2047:128/256'):    912
  test_bitmap: scnprintf("%*pbl", '0-32767'):    5977
  test_bitmap: test_bitmap_read_perf:        1191082
  test_bitmap: test_bitmap_write_perf:        1270153
  test_bitmap: failed 1 out of 208655 tests

It happens mainly when CONFIG_INIT_STACK_ALL_PATTERN is set.

Commit 6b5a4b687367 ("bitmap: Add test for out-of-boundary
modifications for scatter & gather") extended the test to
out-of-boundary bits, but those bits were left uninitialised.

Properly initialise the entire result bitmap before the test.

[Yury: minor commit message tweaks]

Reported-by: Erhard Furtner 
Closes: https://lore.kernel.org/all/ca3547ae-8b79-43a2-a758-23ec980bfd9a@mailbox.org
Fixes: 6b5a4b687367 ("bitmap: Add test for out-of-boundary modifications for scatter & gather")
Signed-off-by: Christophe Leroy (CS GROUP) 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Yury Norov 
Signed-off-by: Sasha Levin

Revert "once: don't use a work queue to reset sleepable static key"

2026-09-11T09:50:55+00:00

commit 0ba6912f7e974045dcdd170f022cba19247e00bc upstream.

This reverts commit e8eef69a99f185e75909adb24ab93d706e07bf27.

While DO_ONCE_SLEEPABLE() is used from sleepable/process context, callers
may still be holding arbitrary subsystem locks.

For instance, __inet_hash_connect() uses get_random_sleepable_once() which
invokes DO_ONCE_SLEEPABLE() while holding the socket lock (sk_lock):

  lock_sock(sk)
    __inet_hash_connect()
      get_random_sleepable_once()
        DO_ONCE_SLEEPABLE()
          __do_once_sleepable_done()
            static_branch_disable()
              static_key_disable()
                cpus_read_lock()

Calling static_branch_disable() directly from __do_once_sleepable_done()
causes static_key_disable() to synchronously acquire cpus_read_lock()
(cpu_hotplug_lock) and jump_label_mutex inside the caller's lock context.

This introduces an unwanted lockdep dependency:
  sk_lock -> cpu_hotplug_lock

Because cpu_hotplug_lock depends on fs_reclaim (via workqueue CPU bringup
allocating memory with GFP_KERNEL), and storage/block layers (such as
NVMe-TCP) acquire sk_lock during I/O dispatch, lockdep reports circular
locking dependencies:

  set->srcu -> sk_lock -> cpu_hotplug_lock -> fs_reclaim -> q_usage_counter -> elevator_lock -> set->srcu

This false positive previously prompted commit 19bdb70c77d3 ("nvme-tcp:
lockdep: use dynamic lockdep keys per socket instance") to work around the
warning using per-socket dynamic keys in NVMe-TCP.  That in turn broke
asynchronous socket teardown and caused syzbot warnings in
tcp_tsq_handler().

Restoring once_disable_jump() in __do_once_sleepable_done() ensures that
static_branch_disable() is executed asynchronously from a system workqueue
without holding the caller's locks.

Link: https://lore.kernel.org/20260825142515.1965654-1-edumazet@google.com
Fixes: e8eef69a99f1 ("once: don't use a work queue to reset sleepable static key")
Signed-off-by: Eric Dumazet 
Closes: https://lore.kernel.org/lkml/ao0mwtt8ePAINFni@shinhome/
Reported-by: Shin'ichiro Kawasaki 
Cc: Tony Luck 
Cc: Reinette Chatre 
Cc: Keith Busch 
Cc: Nilay Shroff 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

xarray: honor XA_FLAGS_ACCOUNT in xas_split_alloc()

2026-09-07T15:37:27+00:00

commit 789763523fb43cdc328de5cb5dcd19240ccf90d8 upstream.

XArray operations that allocate xa_nodes, such as xas_nomem() and
xas_alloc(), add __GFP_ACCOUNT when the array has XA_FLAGS_ACCOUNT set.
This charges the allocated memory and avoids the workingset convergence
issue described by commit 7b785645e8f13 ("mm: fix page cache convergence
regression").

xas_split_alloc() does not add _GFP_ACCOUNT when XA_FLAGS_ACCOUNT is
present.  Fix it.

Link: https://lore.kernel.org/20260804-add-gfp_account-to-xas_split_alloc-v3-2-38cb3ff325c5@nvidia.com
Fixes: 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache")
Signed-off-by: Zi Yan 
Reviewed-by: Lorenzo Stoakes (ARM) 
Acked-by: Johannes Weiner 
Cc: Baolin Wang 
Cc: Barry Song 
Cc: David Hildenbrand 
Cc: Dev Jain 
Cc: Lance Yang 
Cc: Liam R. Howlett 
Cc: Matthew Wilcox (Oracle) 
Cc: Ryan Roberts 
Cc: William Kucharski 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

block: validate user space vectors during extraction

2026-09-07T15:36:55+00:00

commit 14b007e178811db72fbb1ebb3535160db6ec1e6a upstream.

The bio-based drivers don't necessarily check the alignment split, and
stacking block drivers don't always handle a misalignment detected after
submitting the bio. Validate user vectors against the device's
dma_alignment as the bio is built from the iov_iter, rejecting
misaligned early with -EINVAL.

Cc: stable@vger.kernel.org
Fixes: 5ff3f74e145a ("block: simplify direct io validity check")
Fixes: 7eac33186957 ("iomap: simplify direct io validity check")
Reviewed-by: Hannes Reinecke 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Keith Busch 
Link: https://patch.msgid.link/20260720201057.1862857-6-kbusch@meta.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()

2026-09-07T15:36:40+00:00

commit cec0d03fe785380540dc1b4d07c80f67ae2ffc78 upstream.

Patch series "lib/ucs2_string.c: fix out-of-bounds read in
ucs2_strnlen()", v2.

This series fixes an off-by-one out-of-bounds read in ucs2_strnlen().

The first patch is the real fix, the second patch comes as a bonus and
fixes the code indentation.


This patch (of 2):

ucs2_strnlen() checks the current character before checking whether the
caller-provided maximum length has been reached.  If the input is not
NUL-terminated within that bound, the loop can read one ucs2_char_t past
the limit.

Test the length before dereferencing to prevent an off-by-one
out-of-bounds read.

Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-0-9ea94e32a358@kernel.org
Link: https://lore.kernel.org/20260723-fix-ucs2_strnlen-v2-1-9ea94e32a358@kernel.org
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Vincent Mailhol 
Cc: Kees Cook 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

kcov: fix data corruption and race conditions on PREEMPT_RT

2026-08-27T12:35:23+00:00

commit 2eed77fdcb0cc48e8eccb2bcd4b7f2c6d650e84c upstream.

syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the
temporary storage used for saving/restoring remote KCOV state is currently
allocated as the per-CPU area.

On PREEMPT_RT kernels, softirq handlers run as preemptible task threads
(e.g., ksoftirqd). If a softirq context preempts a task running a remote
KCOV session, it safely saves the task's state into the per-CPU area.
However, if that softirq thread is subsequently preempted by a higher-
priority softirq thread on the same CPU, the second softirq will overwrite
the same per-CPU area, permanently destroying the original task's KCOV
state.

Fix this data corruption by moving the temporary storage from the per-CPU
area to the per-thread area. Since each softirq thread now owns its own
task context, nested softirq preemption no longer causes data overwrites.

Note that while the temporary storage is now on a per-thread basis, the
per-CPU kcov_percpu_data.lock must be retained, for we need to ensure that
kcov_remote_start() and kcov_remote_stop() operate atomically without
racing against asynchronous interrupts that manipulate the current task's
KCOV state.

It is likely that GFP_KERNEL allocation by vmalloc_node() in kcov_init()
has already called panic() before returning NULL, for there will be no
OOM-killable userspace processes when __init function of built-in module
runs. But this patch also fixes crashing the kernel when vmalloc_node()
in kcov_init() returned NULL, for kcov_init() left per-CPU irq_area == NULL
but kcov_remote_start() depends on per-CPU irq_area != NULL, resulting in

  (1) doing vmalloc() in kcov_remote_start() despite !in_task() context

  (2) out-of-array-bounds access if (1) succeeded but
      kcov->remote_size < CONFIG_KCOV_IRQ_AREA_SIZE

  (3) always leak memory allocated by (1), eventually killing all
      OOM-killable userspace processes

problems.

Link: https://lore.kernel.org/43552d09-2ce2-4b19-b0d3-a2d1ab952145@I-love.SAKURA.ne.jp
Reported-by: syzbot+3f51ad7ac3ae57a6fdcc@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=3f51ad7ac3ae57a6fdcc
Reported-by: syzbot+47cf95ca1f9dcca872c8@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=47cf95ca1f9dcca872c8
Reported-by: syzbot+8a173e13208949931dc7@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8a173e13208949931dc7
Reported-by: syzbot+90984d3713722683112e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=90984d3713722683112e
Analyzed-by: AI Mode in Google Search (no mail address)
Fixes: 5ff3b30ab57d ("kcov: collect coverage from interrupts")
Signed-off-by: Tetsuo Handa 
Reviewed-by: Alexander Potapenko 
Cc: Alan Stern 
Cc: Andrey Konovalov 
Cc: Christoph Hellwig 
Cc: Clark Williams 
Cc: Dmitry Vyukov 
Cc: Greg Kroah-Hartman 
Cc: Marco Elver 
Cc: Mark Brown 
Cc: Roman Gushchin 
Cc: Sebastian Andrzej Siewior 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman