huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2025-38498: kernel: do_change_type(): refuse to operate on unmounted/not ours mounts
Component: kernel
Severity: Moderate
CVSS v3: 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:H)
Public date: 2025-07-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

do_change_type(): refuse to operate on unmounted/not ours mounts

Ensure that propagation settings can only be changed for mounts located
in the caller's mount namespace. This change aligns permission checking
with the rest of mount(2).

Statement: A flaw in do_change_type() allowed a process to change mount propagation flags on mounts outside its own mount namespace, breaking expected isolation guarantees. This could enable a local attacker with mount privileges to disrupt or alter mount behavior in other namespaces, potentially causing system-wide denial of service.

Affected upstream versions: 2.6.15
Fixed upstream versions: 0, 5.10.239, 5.15.186, 5.4.295, 6.1.142, 6.12.34, 6.15.3, 6.16, 6.6.94
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 787937c4e373f1722c4343e5a5a4eb0f8543e589
CVE-2025-38499: kernel: clone_private_mnt(): make sure that caller has CAP_SYS_ADMIN in the right userns
Component: kernel
Severity: Important
CWE: CWE-266 (Incorrect Privilege Assignment)
CVSS v3: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-08-11T00:00:00+00:00

A vulnerability was found in clone_private_mount in fs/namespace.c in filesystem subsystem in the Linux Kernel.This flaw could allow a local attacker to crash the system or leak kernel internal information.

Statement: clone_private_mount() lacked a ns_capable(..., CAP_SYS_ADMIN) check for the user namespace that owns the target mount namespace. A local attacker in a user/mount namespace could privately clone a mount and expose content hidden by mounts they are not allowed to undo, effectively bypassing mount policy (confidentiality impact and sometimes integrity too).

Affected upstream versions: 4.4.281 < 4.5, 4.9.280 < 4.10, 4.14.244 < 4.15, 4.19.204 < 4.20, 5.4.141 < 5.5, 5.10.59 < 5.11, 5.13.11 < 5.14, 5.14
Fixed upstream versions: 0, 4.10, 4.15, 4.20, 4.5, 5.11, 5.14, 5.15.190, 5.5, 6.1.147, 6.12.40, 6.15.3, 6.16, 6.6.100
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 36fecd740de2d542d2091d65d36554ee2bcf9c65
CVE-2025-38523: kernel: cifs: Fix the smbd_response slab to allow usercopy
Component: kernel
Severity: Moderate
CWE: CWE-1188 (Initialization of a Resource with an Insecure Default)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-08-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix the smbd_response slab to allow usercopy

The handling of received data in the smbdirect client code involves using
copy_to_iter() to copy data from the smbd_reponse struct's packet trailer
to a folioq buffer provided by netfslib that encapsulates a chunk of
pagecache.

If, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks
then performed in copy_to_iter() oopsing with something like the following:

 CIFS: Attempting to mount //172.31.9.1/test
 CIFS: VFS: RDMA transport established
 usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)!
 ------------[ cut here ]------------
 kernel BUG at mm/usercopy.c:102!
 ...
 RIP: 0010:usercopy_abort+0x6c/0x80
 ...
 Call Trace:
  <TASK>
  __check_heap_object+0xe3/0x120
  __check_object_size+0x4dc/0x6d0
  smbd_recv+0x77f/0xfe0 [cifs]
  cifs_readv_from_socket+0x276/0x8f0 [cifs]
  cifs_read_from_socket+0xcd/0x120 [cifs]
  cifs_demultiplex_thread+0x7e9/0x2d50 [cifs]
  kthread+0x396/0x830
  ret_from_fork+0x2b8/0x3b0
  ret_from_fork_asm+0x1a/0x30

The problem is that the smbd_response slab's packet field isn't marked as
being permitted for usercopy.

Fix this by passing parameters to kmem_slab_create() to indicate that
copy_to_iter() is permitted from the packet region of the smbd_response
slab objects, less the header space.


Affected upstream versions: 6.12
Fixed upstream versions: 0, 6.12.36, 6.15.8, 6.16
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 87dcc7e33fc3dcb8ed32333cec016528b5bb6ce4
CVE-2025-38527: kernel: smb: client: fix use-after-free in cifs_oplock_break
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-08-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix use-after-free in cifs_oplock_break

A race condition can occur in cifs_oplock_break() leading to a
use-after-free of the cinode structure when unmounting:

  cifs_oplock_break()
    _cifsFileInfo_put(cfile)
      cifsFileInfo_put_final()
        cifs_sb_deactive()
          [last ref, start releasing sb]
            kill_sb()
              kill_anon_super()
                generic_shutdown_super()
                  evict_inodes()
                    dispose_list()
                      evict()
                        destroy_inode()
                          call_rcu(&inode->i_rcu, i_callback)
    spin_lock(&cinode->open_file_lock)  <- OK
                            [later] i_callback()
                              cifs_free_inode()
                                kmem_cache_free(cinode)
    spin_unlock(&cinode->open_file_lock)  <- UAF
    cifs_done_oplock_break(cinode)       <- UAF

The issue occurs when umount has already released its reference to the
superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this
releases the last reference, triggering the immediate cleanup of all
inodes under RCU. However, cifs_oplock_break() continues to access the
cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the
entire oplock break operation. This ensures that the superblock and
its inodes remain valid until the oplock break completes.


Affected upstream versions: 3.16.72 < 3.17, 4.9.171 < 4.10, 4.14.114 < 4.15, 4.19.37 < 4.20, 5.0.10 < 5.1, 5.1
Fixed upstream versions: 0, 3.17, 4.10, 4.15, 4.20, 5.1, 5.15.190, 6.1.147, 6.12.40, 6.15.8, 6.16, 6.6.100
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4256a483fe58af66a46cbf3dc48ff26e580d3308
CVE-2025-38550: kernel: ipv6: mcast: Delay put pmc->idev in mld_del_delrec()
Component: kernel
Severity: Moderate
CVSS v3: 7.1 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H)
Public date: 2025-08-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ipv6: mcast: Delay put pmc->idev in mld_del_delrec()

pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec()
does, the reference should be put after ip6_mc_clear_src() return.

Statement: An IPv6 MLD bookkeeping bug freed pmc->idev before it was used in ip6_mc_clear_src(), causing a use-after-free in the multicast code path. A remote attacker on the same L2 segment could potentially trigger a kernel crash via crafted MLD activity, leading to DoS.

Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.190, 6.1.147, 6.12.40, 6.15.8, 6.16, 6.6.100
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1b5b413094af8d88a31b5df3fd262f6baca53841
CVE-2025-38556: kernel: HID: core: Harden s32ton() against conversion to 0 bits
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-08-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

HID: core: Harden s32ton() against conversion to 0 bits

Testing by the syzbot fuzzer showed that the HID core gets a
shift-out-of-bounds exception when it tries to convert a 32-bit
quantity to a 0-bit quantity.  Ideally this should never occur, but
there are buggy devices and some might have a report field with size
set to zero; we shouldn't reject the report or the device just because
of that.

Instead, harden the s32ton() routine so that it returns a reasonable
result instead of crashing when it is called with the number of bits
set to 0 -- the same as what snto32() does.

Statement: HID core could crash on malformed devices that define a 0-bit report field, causing a shift-out-of-bounds in s32ton(). Exploitation requires only connecting a malicious HID device (no privileges or user interaction), leading to kernel crash.

Affected upstream versions: 2.6.20
Fixed upstream versions: 0, 5.10.248, 5.15.198, 6.1.159, 6.12.46, 6.15.10, 6.16.1, 6.17, 6.6.119
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6cdf6c708717c5c6897d0800a1793e83757c7491
CVE-2025-38566: kernel: sunrpc: fix handling of server side tls alerts
Component: kernel
Severity: Moderate
CWE: CWE-754 (Improper Check for Unusual or Exceptional Conditions)
CVSS v3: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-08-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

sunrpc: fix handling of server side tls alerts

Scott Mayhew discovered a security exploit in NFS over TLS in
tls_alert_recv() due to its assumption it can read data from
the msg iterator's kvec..

kTLS implementation splits TLS non-data record payload between
the control message buffer (which includes the type such as TLS
aler or TLS cipher change) and the rest of the payload (say TLS
alert's level/description) which goes into the msg payload buffer.

This patch proposes to rework how control messages are setup and
used by sock_recvmsg().

If no control message structure is setup, kTLS layer will read and
process TLS data record types. As soon as it encounters a TLS control
message, it would return an error. At that point, NFS can setup a
kvec backed msg buffer and read in the control message such as a
TLS alert. Msg iterator can advance the kvec pointer as a part of
the copy process thus we need to revert the iterator before calling
into the tls_alert_recv.

Statement: A remotely reachable flaw in the SUNRPC NFS-over-TLS server could allow a client to trigger a kernel crash by sending a crafted TLS alert. The issue lies in how the kernel processes TLS control messages, which can lead to use-after-free or invalid memory accesses during alert handling.

The attack vector is network-based (AV:N), but the required privileges vary with deployment: in many configurations, a client must already possess valid credentials or a certificate to establish an NFS/TLS session, which corresponds to PR:L in CVSS. If the server is configured to accept connections without strict authentication, exploitation could occur with PR:N, but the more common and realistic scenario is PR:L.

Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.12.42, 6.15.10, 6.16.1, 6.17, 6.6.102
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b1df394621710b312f0393e3f240fdac0764f968
CVE-2025-38568: kernel: net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing
Component: kernel
Severity: Moderate
CWE: CWE-129 (Improper Validation of Array Index)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-08-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net/sched: mqprio: fix stack out-of-bounds write in tc entry parsing

TCA_MQPRIO_TC_ENTRY_INDEX is validated using
NLA_POLICY_MAX(NLA_U32, TC_QOPT_MAX_QUEUE), which allows the value
TC_QOPT_MAX_QUEUE (16). This leads to a 4-byte out-of-bounds stack
write in the fp[] array, which only has room for 16 elements (0–15).

Fix this by changing the policy to allow only up to TC_QOPT_MAX_QUEUE - 1.

Statement: A bounds-check bug in mqprio TC entry parsing allows a 4-byte stack out-of-bounds write when TCA_MQPRIO_TC_ENTRY_INDEX equals 16, causing kernel crashes. Exploitation requires local netlink access with CAP_NET_ADMIN (often within the relevant network namespace). No practical confidentiality or integrity impact is evident due to tight value constraints enforced by the netlink policy.

Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.12.42, 6.15.10, 6.16.1, 6.17, 6.6.102
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 39491e859fd494d0b51adc5c7d54c8a7dcf1d198
CVE-2025-38571: kernel: sunrpc: fix client side handling of tls alerts
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-08-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

sunrpc: fix client side handling of tls alerts

A security exploit was discovered in NFS over TLS in tls_alert_recv
due to its assumption that there is valid data in the msghdr's
iterator's kvec.

Instead, this patch proposes the rework how control messages are
setup and used by sock_recvmsg().

If no control message structure is setup, kTLS layer will read and
process TLS data record types. As soon as it encounters a TLS control
message, it would return an error. At that point, NFS can setup a kvec
backed control buffer and read in the control message such as a TLS
alert. Scott found that a msg iterator can advance the kvec pointer
as a part of the copy process thus we need to revert the iterator
before calling into the tls_alert_recv.

Statement: A remotely reachable bug in the SUNRPC NFS-over-TLS client allowed a server to trigger a kernel crash by sending a TLS alert when the client assumed a valid control kvec in the message iterator. It requires NFS over TLS to be enabled on the client.
Exploitation is only possible in configurations where NFS over TLS is enabled, as the bug lies in the handling of TLS alert control messages in sunrpc. A remote attacker controlling an NFS/TLS session could send a crafted TLS alert to trigger a kernel crash on the client, leading to denial of service. However, since NFS over TLS is not enabled by default on most systems, the practical severity is lower unless explicitly deployed.

Affected upstream versions: 6.5
Fixed upstream versions: 0, 6.12.42, 6.15.10, 6.16.1, 6.17, 6.6.102
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a55b3d15331859d9fdd261cfa6d34ca2aeb0fb95
CVE-2025-38572: kernel: ipv6: reject malicious packets in ipv6_gso_segment()
Component: kernel
Severity: Moderate
CWE: CWE-120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
CVSS v3: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H)
Public date: 2025-08-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ipv6: reject malicious packets in ipv6_gso_segment()

syzbot was able to craft a packet with very long IPv6 extension headers
leading to an overflow of skb->transport_header.

This 16bit field has a limited range.

Add skb_reset_transport_header_careful() helper and use it
from ipv6_gso_segment()

WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]
WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151
Modules linked in:
CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]
 RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151
Call Trace:
 <TASK>
  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53
  nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110
  skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53
  __skb_gso_segment+0x342/0x510 net/core/gso.c:124
  skb_gso_segment include/net/gso.h:83 [inline]
  validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950
  validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000
  sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329
  __dev_xmit_skb net/core/dev.c:4102 [inline]
  __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679


Affected upstream versions: 3.8
Fixed upstream versions: 0, 5.10.241, 5.15.190, 5.4.297, 6.1.148, 6.12.42, 6.15.10, 6.16.1, 6.17, 6.6.102
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5dc60b2a00ed7629214ac0c48e43f40af2078703
CVE-2025-38614: kernel: eventpoll: Fix semi-unbounded recursion
Component: kernel
Severity: Moderate
CWE: CWE-674 (Uncontrolled Recursion)
CVSS v3: 6.2 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-08-19T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

eventpoll: Fix semi-unbounded recursion

Ensure that epoll instances can never form a graph deeper than
EP_MAX_NESTS+1 links.

Currently, ep_loop_check_proc() ensures that the graph is loop-free and
does some recursion depth checks, but those recursion depth checks don't
limit the depth of the resulting tree for two reasons:

 - They don't look upwards in the tree.
 - If there are multiple downwards paths of different lengths, only one of
   the paths is actually considered for the depth check since commit
   28d82dc1c4ed ("epoll: limit paths").

Essentially, the current recursion depth check in ep_loop_check_proc() just
serves to prevent it from recursing too deeply while checking for loops.

A more thorough check is done in reverse_path_check() after the new graph
edge has already been created; this checks, among other things, that no
paths going upwards from any non-epoll file with a length of more than 5
edges exist. However, this check does not apply to non-epoll files.

As a result, it is possible to recurse to a depth of at least roughly 500,
tested on v6.15. (I am unsure if deeper recursion is possible; and this may
have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion
problem").)

To fix it:

1. In ep_loop_check_proc(), note the subtree depth of each visited node,
and use subtree depths for the total depth calculation even when a subtree
has already been visited.
2. Add ep_get_upwards_depth_proc() for similarly determining the maximum
depth of an upwards walk.
3. In ep_loop_check(), use these values to limit the total path length
between epoll nodes to EP_MAX_NESTS edges.

Statement: A local unprivileged user can trigger this issue by creating deeply nested chains of epoll file descriptors using the standard epoll_create and epoll_ctl syscalls. No special capabilities or elevated rights are required — any user with the ability to open file descriptors can exploit it. This can lead to excessive kernel stack usage and ultimately a denial of service (system crash).

Affected upstream versions: 2.6.32.30 < 2.6.33, 2.6.33.8 < 2.6.34, 2.6.34.10 < 2.6.35, 2.6.35.12 < 2.6.36, 2.6.37.3 < 2.6.38, 2.6.38
Fixed upstream versions: 0, 2.6.33, 2.6.34, 2.6.35, 2.6.36, 2.6.38, 5.15.190, 6.1.149, 6.12.43, 6.15.11, 6.16.1, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 71379495ab70eaba19224bd71b5b9b399eb85e04
CVE-2025-38653: kernel: proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 5.1 (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-08-22T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al

Check pde->proc_ops->proc_lseek directly may cause UAF in rmmod scenario. 
It's a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in
proc_get_inode()").  Followed by AI Viro's suggestion, fix it in same
manner.

Statement: A race in procfs could dereference a freed proc_ops->proc_lseek pointer when a /proc file is opened while its backing module is being removed, leading to a kernel UAF and potential crash. The fix mirrors existing read/ioctl handling: it precomputes capability flags on entry creation and checks those flags (not the function pointer) in proc_reg_open(), eliminating the rmmod-time gap. This is primarily a local DoS: an unprivileged user can open/seek a proc entry while an administrator unloads the module.

Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.148, 6.12.42, 6.15.10, 6.16.1, 6.17, 6.6.102
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c35b0feb80b48720dfbbf4e33759c7be3faaebb6
CVE-2025-38683: kernel: hv_netvsc: Fix panic during namespace deletion with VF
Component: kernel
Severity: Moderate
CWE: CWE-820 (Missing Synchronization)
CVSS v3: 5.2 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H)
Public date: 2025-09-04T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

hv_netvsc: Fix panic during namespace deletion with VF

The existing code move the VF NIC to new namespace when NETDEV_REGISTER is
received on netvsc NIC. During deletion of the namespace,
default_device_exit_batch() >> default_device_exit_net() is called. When
netvsc NIC is moved back and registered to the default namespace, it
automatically brings VF NIC back to the default namespace. This will cause
the default_device_exit_net() >> for_each_netdev_safe loop unable to detect
the list end, and hit NULL ptr:

[  231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0
[  231.449656] BUG: kernel NULL pointer dereference, address: 0000000000000010
[  231.450246] #PF: supervisor read access in kernel mode
[  231.450579] #PF: error_code(0x0000) - not-present page
[  231.450916] PGD 17b8a8067 P4D 0
[  231.451163] Oops: Oops: 0000 [#1] SMP NOPTI
[  231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY
[  231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024
[  231.452692] Workqueue: netns cleanup_net
[  231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0
[  231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00
[  231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246
[  231.454610] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 61c8864680b583eb
[  231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: 0000000030766564
[  231.455686] RBP: ff75fc7c9bf9fd78 R08: 0000000000000000 R09: 0000000000000000
[  231.456126] R10: 0000000000000001 R11: 0000000000000004 R12: ff1fa9f70088e340
[  231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340
[  231.457161] FS:  0000000000000000(0000) GS:ff1faa6783a08000(0000) knlGS:0000000000000000
[  231.457707] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  231.458031] CR2: 0000000000000010 CR3: 0000000179ab2006 CR4: 0000000000b73ef0
[  231.458434] Call Trace:
[  231.458600]  <TASK>
[  231.458777]  ops_undo_list+0x100/0x220
[  231.459015]  cleanup_net+0x1b8/0x300
[  231.459285]  process_one_work+0x184/0x340

To fix it, move the ns change to a workqueue, and take rtnl_lock to avoid
changing the netdev list when default_device_exit_net() is using it.


Affected upstream versions: 5.10.229 < 5.10.241, 5.15.170 < 5.15.190, 6.1.115 < 6.1.149, 6.6.59 < 6.6.103, 4.19.323 < 4.20, 5.4.285 < 5.5, 6.11.6 < 6.12, 6.12
Fixed upstream versions: 0, 4.20, 5.10.241, 5.15.190, 5.5, 6.1.149, 6.12, 6.12.43, 6.15.11, 6.16.2, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3ca41ab55d23a0aa71661a5a56a8f06c11db90dc