linux-stable.git, branch v7.1.5

Linux 7.1.5

2026-07-24T14:21:27+00:00

Link: https://lore.kernel.org/r/20260721152552.646164743@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Salvatore Bonaccorso 
Tested-by: Brett A C Sheffield 
Tested-by: Peter Schneider 
Tested-by: Ron Economos 
Tested-by: Takeshi Ogasawara 
Link: https://lore.kernel.org/r/20260722142947.085426486@linuxfoundation.org
Tested-by: Ronald Warsow 
Tested-by: Brett A C Sheffield 
Tested-by: Jeffrin Jose T 
Tested-by: Shuah Khan 
Tested-by: Pavel Machek (CIP) 
Tested-by: Florian Fainelli 
Tested-by: Justin M. Forbes 
Tested-by: Barry K. Nathan 
Tested-by: Takeshi Ogasawara 
Tested-by: Miguel Ojeda 
Tested-by: Mark Brown 
Tested-by: Peter Schneider 
Tested-by: Benjamin Boortz 
Signed-off-by: Greg Kroah-Hartman

Revert "gpib: cb7210: Fix region leak when request_irq fails"

2026-07-24T14:21:26+00:00

commit 285ecb7d9e1b2401c2eccca4d0f26615f4d651eb upstream.

This reverts commit 5ad28496055858166eb2268344c8fda2c26d3561.

Turns out not to be correct.

Link: https://lore.kernel.org/r/PpNUbGhrvT8I_KayoDvQYI2PYjmMw1QEkuVBDZz2PwBsVVgPkBXJarc2mBM0IhiH3AQG0GtgqEsDRXNj3yUKEDBaZa25u73pAjvcE6vfRsg=@protonmail.com
Reported-by: Dominik Karol Piątkowski 
Cc: Mark Brown 
Cc: Hongling Zeng 
Cc: Hongling Zeng 
Signed-off-by: Greg Kroah-Hartman

posix-cpu-timers: Prevent UAF caused by non-leader exec() race

2026-07-24T14:21:26+00:00

commit 920f893f735e92ba3a1cd9256899a186b161928d upstream.

Wongi and Jungwoo decoded and reported a non-leader exec() related race
which can result in an UAF:

 sys_timer_delete()			exec()
   posix_cpu_timer_del()
   // Observes old leader
   p = pid_task(pid, pid_type);		de_thread()
   					  switch_leader();
					  release_task(old_leader)
					    __exit_signal(old_leader)
					      sighand = lock(old_leader, sighand);
					      posix_cpu_timers*_exit();
   sighand = lock_task_sighand(p)	      unhash_task(old_leader);
     sh = lock(p, sighand)	    	      old_leader->sighand = NULL;
					      unlock(sighand);
     (p->sighand == NULL)
	unlock(sh)
	return NULL;

   // Returns without action
   if(!sighand)
      return 0;
   free_posix_timer();

This is "harmless" unless the deleted timer was armed and enqueued in
p->signal because on exec() a TGID targeted timer is inherited.

As sys_timer_delete() freed the underlying posix timer object
run_posix_cpu_timers() or any timerqueue related add/delete operations on
other timers will access the freed object's timerqueue node, which results
in an UAF.

There is a similar problem vs. posix_cpu_timer_set(). For regular posix
timers it just transiently returns -ESRCH to user space, but for the use
case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is
allocated on the stack.

Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops
to expire.

While debating solutions Frederic pointed out another problem:

   posix_cpu_timer_del(tmr)
					__exit_signal(p)
					  posix_cpu_timers*_exit(p);
					  unhash_task(p);
					  p->sighand = NULL;
     sh = lock_task_sighand(p)
        sighand = p->sighand;
	if (!sighand)
	    return NULL;
	lock(sighand);

     if (!sh)
	WARN_ON_ONCE(timer_queued(tmr));

On weakly ordered architectures it is not guaranteed that
posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit()
when p->sighand is observed as NULL, which means the WARN() can be a false
positive.

Solve these issues by:

  1) Changing the store in __exit_signal() to smp_store_release().

  2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path
     of lock_task_sighand().

  3) Creating a helper function for looking up the task and locking sighand
     which does not return when sighand == NULL. Instead it retries the
     task lookup and only if that fails it gives up.

  4) Using that helper in the three affected functions.

observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit()
and the ones in unhash_task().

gracefully. When the task lookup returns the old leader, but sighand ==
NULL then it retries. In the non-leader exec() case the subsequent task
lookup will observe the new leader due to #1/#2. In normal exit() scenarios
the subsequent lookup fails.

When the task lookup fails, the function also checks whether the timer is
still enqueued and issues a warning if that's the case. Unfortunately there
is nothing which can be done about it, but as the task is already not
longer visible the timer should not be accessed anymore. This check also
requires memory ordering, which is not provided when the first lookup
fails. To achieve that the check is preceeded by a smp_rmb() which pairs
with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that
the stores in posix_cpu_timers*_exit() are visible.

The history of the non-leader exec() issue goes back to the early days of
posix CPU timers, which stored a pointer to the group leader task in the
timer. That obviously fails when a non-leader exec() switches the leader.
commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems
with mt exec") added a temporary workaround for that in 2010 which survived
about 10 years. The fix for the workaround changed the task pointer to a
pid pointer, but failed to see the subtle race described above. So the
Fixes tag picks that commit, which seems to be halfways accurate.

Thanks to Frederic Weissbecker, Oleg Nesterov and Peter Zijlstra for
review, feedback and suggestions and to Wongi and Jungwoo for the excellent
bug report and analysis!

Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task")
Reported-by: Wongi Lee 
Reported-by: Jungwoo Lee 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Oleg Nesterov 
Cc: stable@vger.kernel.org
Signed-off-by: Salvatore Bonaccorso 
Signed-off-by: Greg Kroah-Hartman

posix-timers: Expand timer_[re]arm() callbacks with a boolean return value

2026-07-24T14:21:26+00:00

commit 6fdb2677a594ab38eade927919bbd4d9688bfa1c upstream.

In order to catch expiry times which are already in the past the
timer_arm() and timer_rearm() callbacks need to be able to report back to
the caller whether the timer has been queued or not.

Change the function signature and let all implementations return true for
now. While at it simplify posix_cpu_timer_rearm().

No functional change intended.

Signed-off-by: Thomas Gleixner 
Reviewed-by: Frederic Weisbecker 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: John Stultz 
Link: https://patch.msgid.link/20260408114952.130222296@kernel.org
Signed-off-by: Salvatore Bonaccorso 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix Color Manager (3DLUT, Shaper, Blend)

2026-07-24T14:21:26+00:00

commit 12f58a6caad3be54d7788b338b3f57d7c17bbef7 upstream.

[WHY & HOW]
The original refactor and fixes are causing regressions.
Revert them for now until they can be resolved

Fixes: e56e3cff2a1b ("drm/amd/display: Sync dcn42 with DC 3.2.373")
Reviewed-by: Tom Chung 
Signed-off-by: Dillon Varone 
Signed-off-by: James Lin 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

iomap: consolidate bio submission

2026-07-24T14:21:26+00:00

[ Upstream commit 044472d5ee7d71f918fa3f61bd65e4933a0c006e ]

Add a iomap_bio_submit_read_endio helper factored out of
iomap_bio_submit_read to that all ->submit_read implementations for
iomap_read_ops that use iomap_bio_read_folio_range can shared the
logic.

Right now that logic is mostly trivial, but already has a bug for XFS
because the XFS version is too trivial:  file system integrity validation
needs a workqueue context and thus can't happen from the default iomap
bi_end_io I/O handler.  Unfortunately the iomap refactoring just before
fs integrity landed moved code around here and the call go misplaced,
meaning it never got called.  The PI information still is verified by
the block layer, but the offloading is less efficient (and the future
userspace interface can't get at it).

Fixes: 0b10a370529c ("iomap: support T10 protection information")
Cc: stable@vger.kernel.org # v7.1
Signed-off-by: Christoph Hellwig 
Link: https://patch.msgid.link/20260629121750.3392300-2-hch@lst.de
Acked-by: Namjae Jeon 
Reviewed-by: "Darrick J. Wong" 
Reviewed-by: Joanne Koong 
Signed-off-by: Christian Brauner (Amutable) 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

exfat: fix implicit declaration of brelse()

2026-07-24T14:21:26+00:00

[ Upstream commit f0d1b2e1e02c11e29c953f22a485449e3da2a575 ]

exfat_cluster_walk() calls brelse(bh) without including the header that
declares the function, causing the following build error:

    fs/exfat/exfat_fs.h:542:9: error: implicit declaration of function ‘brelse’ [-Werror=implicit-function-declaration]

Fix this by adding the missing buffer_head.h in exfat_fs.h.

Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon 
Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

exfat: add data_start_bytes and exfat_cluster_to_phys_bytes() helper

2026-07-24T14:21:26+00:00

[ Upstream commit 3b9450beeb961c7ddf4cccddba37fcfa6d1fcb7a ]

This caches the data area start offset in bytes (data_start_bytes)
and introduces a helper function exfat_cluster_to_phys_bytes() to compute
the physical byte position of a given cluster.

Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon 
Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

exfat: add balloc parameter to exfat_map_cluster() for iomap support

2026-07-24T14:21:26+00:00

[ Upstream commit 3474416bb9abafca2e79b7ff700a100b7e8bc766 ]

In preparation for supporting the iomap infrastructure, we need to know
whether a new cluster was allocated or not in exfat_map_cluster().

Add an optional 'bool *balloc' output parameter. When a new cluster is
allocated, *balloc is set to true. Pass NULL from exfat_get_block() to
preserve the existing behavior.

Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon 
Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

exfat: replace unsafe macros with static inline functions

2026-07-24T14:21:26+00:00

[ Upstream commit f07db38084dc45162d5fe2871ed72674ddc0f9ae ]

The current exFAT driver relies on various macros for unit conversions
between clusters, blocks, sectors, and directory entries. These macros
are structurally unsafe as they lack type enforcement and are prone to
potential integer overflows during bit-shift operations, especially
on 64-bit architectures. Replace all arithmetic macros with static inline
functions to provide strict type checking and explicit casting.

Acked-by: Christoph Hellwig 
Acked-by: "Darrick J. Wong" 
Signed-off-by: Namjae Jeon 
Stable-dep-of: 044472d5ee7d ("iomap: consolidate bio submission")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman