linux-stable.git, branch v6.12.99

Linux 6.12.99

2026-07-29T15:49:03+00:00

Signed-off-by: Greg Kroah-Hartman

mm: refactor mm_access() to not return NULL

2026-07-29T15:49:03+00:00

[ Upstream commit cd3f8467afd470ccab0de2fbc7c76664af4a0bac ]

mm_access() can return NULL if the mm is not found, but this is handled
the same as an error in all callers, with some translating this into an
-ESRCH error.

Only proc_mem_open() returns NULL if no mm is found, however in this case
it is clearer and makes more sense to explicitly handle the error.
Additionally we take the opportunity to refactor the function to eliminate
unnecessary nesting.

Simplify things by simply returning -ESRCH if no mm is found - this both
eliminates confusing use of the IS_ERR_OR_NULL() macro, and simplifies
callers which would return -ESRCH by returning this error directly.

[lorenzo.stoakes@oracle.com: prefer neater pointer error comparison]
  Link: https://lkml.kernel.org/r/2fae1834-749a-45e1-8594-5e5979cf7103@lucifer.local
Link: https://lkml.kernel.org/r/20240924201023.193135-1-lorenzo.stoakes@oracle.com
Signed-off-by: Lorenzo Stoakes 
Suggested-by: Arnd Bergmann 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Sasha Levin

Linux 6.12.98

2026-07-25T06:02:24+00:00

Signed-off-by: Greg Kroah-Hartman

ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation

2026-07-25T06:02:24+00:00

The backport of upstream commit c143957520c6 ("ext4: validate donor
file superblock early in EXT4_IOC_MOVE_EXT") uses a bare 'return -EXDEV'
which is safe upstream because the fd is managed via CLASS(fd) with
automatic cleanup (commit 8152f8201088 ("fdget(), more trivial
conversions")).

However, on 6.12.y the ioctl still uses the traditional fdget/fdput
pattern, so the bare return bypasses fdput(donor) at the mext_out label,
leaking the file reference.

Fix by setting err and using goto mext_out.

Fixes: 74796e886ca3 ("ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT")
Reported-by: Harshit Mogalapalli 
Signed-off-by: Yun Zhou 
Signed-off-by: Greg Kroah-Hartman

Linux 6.12.97

2026-07-24T14:11:57+00:00

Link: https://lore.kernel.org/r/20260721152446.065700225@linuxfoundation.org
Tested-by: Salvatore Bonaccorso 
Tested-by: Brett A C Sheffield 
Tested-by: Dominique Martinet 
Tested-by: Peter Schneider 
Tested-by: Francesco Dolcini 
Tested-by: Ron Economos 
Tested-by: Shuah Khan 
Tested-by: Pavel Machek (CIP) 
Link: https://lore.kernel.org/r/20260722142834.868902312@linuxfoundation.org
Tested-by: Brett A C Sheffield 
Tested-by: Pavel Machek (CIP) 
Tested-by: Florian Fainelli 
Tested-by: Peter Schneider 
Tested-by: Shung-Hsi Yu 
Tested-by: Miguel Ojeda 
Signed-off-by: Greg Kroah-Hartman

selftests/bpf: Add simple strscpy() implementation

2026-07-24T14:11:57+00:00

commit 63c49efc987afefc6b9bb7de083eb8748e0b1789 upstream.

Replace bpf_strlcpy() in bpf_util.h with a sized_strscpy(), which is a
simplified sized_strscpy() from the kernel (lib/string.c [1]). It:
  * takes a count (destination size) parameter
  * guarantees NULL-termination
  * returns the number of characters copied or -E2BIG

Re-define strscpy macro similar to in-kernel implementation [2]: allow
the count parameter to be optional.

Add #ifdef-s to tools/include/linux/args.h, as they may be defined in
other system headers (for example, __CONCAT in sys/cdefs.h).

Fixup the single existing bpf_strlcpy() call in cgroup_helpers.c

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/string.c?h=v6.19#n113
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/string.h?h=v6.19#n91

Signed-off-by: Ihor Solodrai 
Link: https://lore.kernel.org/r/20260223190736.649171-2-ihor.solodrai@linux.dev
Signed-off-by: Alexei Starovoitov 
Stable-dep-of: 55ffbe8a15b1 ("selftests/bpf: Initialize operation name before use")
Closes: https://lore.kernel.org/stable/al8dSv_OvhwxFCar@u94a
Signed-off-by: Shung-Hsi Yu 
Signed-off-by: Greg Kroah-Hartman

tools/testing: add linux/args.h header and fix radix, VMA tests

2026-07-24T14:11:56+00:00

commit 9a6a6a3191574a01dcf7a7d9385246d7bc8736bc upstream.

Commit 857d18f23ab1 ("cleanup: Introduce ACQUIRE() and ACQUIRE_ERR() for
conditional locks") accidentally broke the radix tree, VMA userland tests
by including linux/args.h which is not present in the tools/include
directory.

This patch copies this over and adds an #ifdef block to avoid duplicate
__CONCAT declaration in conflict with system headers when we ultimately
include this.

Link: https://lkml.kernel.org/r/20250811052654.33286-1-lorenzo.stoakes@oracle.com
Fixes: 857d18f23ab1 ("cleanup: Introduce ACQUIRE() and ACQUIRE_ERR() for conditional locks")
Signed-off-by: Lorenzo Stoakes 
Cc: Jann Horn 
Cc: John Hubbard 
Cc: Liam Howlett 
Cc: Sidhartha Kumar 
Cc: Vlastimil Babka 
Cc: Dan Williams 
Cc: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Stable-dep-of: 63c49efc987a ("selftests/bpf: Add simple strscpy() implementation")
Signed-off-by: Shung-Hsi Yu 
Signed-off-by: Greg Kroah-Hartman

dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()

2026-07-24T14:11:56+00:00

commit d2e914a4a0d0f753dbae830264850d044026167c upstream.

When a dpll_pin is shared across multiple dpll_device instances and
those devices are being unregistered (e.g. during driver module removal),
a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync().

This happens under the following conditions:
 - A pin is registered with two or more dpll devices (dpll_A, dpll_B)
 - The pin has ref_sync pairs with other pins
 - During unregistration of dpll_A's pins, a ref_sync partner pin is
   unregistered first, removing it from dpll_A->pin_refs
 - But since the partner pin is still registered with dpll_B, its
   dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT
   run and the partner stays in the pin's ref_sync_pins xarray
 - When the pin itself is then unregistered from dpll_A, the delete
   notification calls dpll_msg_add_pin_ref_sync() which finds the
   partner in ref_sync_pins, passes dpll_pin_available() (partner is
   still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A,
   partner) returns NULL because partner was already removed from
   dpll_A->pin_refs
 - The NULL priv pointer is passed to the driver's ref_sync_get
   callback, which dereferences it

 BUG: kernel NULL pointer dereference, address: 0000000000000034
 Oops: Oops: 0000 [#1] SMP NOPTI
 RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x]
 Call Trace:
  dpll_msg_add_pin_ref_sync+0xb8/0x200
  dpll_cmd_pin_get_one+0x3b6/0x4b0
  dpll_pin_event_send+0x72/0x140
  __dpll_pin_unregister+0x5a/0x2b0
  dpll_pin_unregister+0x49/0x70

Fix this by skipping ref_sync pins whose priv pointer cannot be resolved
for the current dpll device.

Fixes: 58256a26bfb3 ("dpll: add reference sync get/set")
Signed-off-by: Ivan Vecera 
Reviewed-by: Vadim Fedorenko 
Reviewed-by: Jiri Pirko 
Link: https://patch.msgid.link/20260710193625.1378822-1-ivecera@redhat.com
Signed-off-by: Paolo Abeni 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: L2CAP: fix tx ident leak for commands without a response

2026-07-24T14:11:56+00:00

commit 6e1930ece855a4c256f1c7e6632d634cfb9888b5 upstream.

Commit 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding
TX ident") changed ident allocation to use an IDA, releasing idents in
l2cap_put_ident() when the matching response command is received.

But identifiers allocated for commands that have no response defined
are never released. In particular L2CAP_LE_CREDITS is sent repeatedly for
the lifetime of an LE CoC channel, so a peer streaming data to the
host exhausts the 1-255 ident range after 254 credit packets. From
then on l2cap_get_ident() fails:

    kernel: Bluetooth: Unable to allocate ident: -28

and every subsequent L2CAP_LE_CREDITS packet is sent with ident 0,
which is invalid (Core Spec, Vol 3, Part A, Section 4: "Signaling
identifier 0x00 is an invalid identifier and shall never be used in
any command"). Remote stacks that validate the ident drop these
commands, never receive new credits, and the channel stalls
permanently. With default socket buffers this happens after roughly 0.5 MB
of received data (the exact amount depends on the socket receive buffer):

  < ACL Data TX: Handle 2048 flags 0x00 dlen 12
        LE L2CAP: LE Flow Control Credit (0x16) ident 0 len 4
          Source CID: 64
          Credits: 1

Release the ident immediately after sending L2CAP_LE_CREDITS since no
response will ever release it. Use a local variable instead of
chan->ident so that an ident that an EXT_FLOWCTL channel may be waiting on
(e.g. a pending reconfigure) is not overwritten by a credit packet.

Also add the missing L2CAP_LE_CONN_RSP case to l2cap_put_ident() so
idents allocated for outgoing L2CAP_LE_CONN_REQ commands are released
when the response arrives.

Fixes: 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding TX ident")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221629
Assisted-by: Claude:claude-opus-4.8
Assisted-by: Fable:5
Signed-off-by: Stig Hornang 
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote netdev

2026-07-24T14:11:56+00:00

commit d38eaf611839b85ade3dd3db309dbc8aaaaf0095 upstream.

b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding
conn ref") don't reset the chan->conn to NULL anymore making the bt#
netdev not be remove once the last l2cap_chan_del is removed.

Instead of restoring the original behavior this remove the logic of
keeping the interface after the last channel is removed because it
never worked as intended and the l2cap_chan_del always detach its
l2cap_conn which results in always removing the channel anyway.

Fixes: b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref")
Signed-off-by: Luiz Augusto von Dentz 
Signed-off-by: Greg Kroah-Hartman