huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-53119: kernel: virtio/vsock: Fix accept_queue memory leak
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L)
Public date: 2024-12-02T00:00:00+00:00

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

virtio/vsock: Fix accept_queue memory leak

As the final stages of socket destruction may be delayed, it is possible
that virtio_transport_recv_listen() will be called after the accept_queue
has been flushed, but before the SOCK_DONE flag has been set. As a result,
sockets enqueued after the flush would remain unremoved, leading to a
memory leak.

vsock_release
  __vsock_release
    lock
    virtio_transport_release
      virtio_transport_close
        schedule_delayed_work(close_work)
    sk_shutdown = SHUTDOWN_MASK
(!) flush accept_queue
    release
                                        virtio_transport_recv_pkt
                                          vsock_find_bound_socket
                                          lock
                                          if flag(SOCK_DONE) return
                                          virtio_transport_recv_listen
                                            child = vsock_create_connected
                                      (!)   vsock_enqueue_accept(child)
                                          release
close_work
  lock
  virtio_transport_do_close
    set_flag(SOCK_DONE)
    virtio_transport_remove_sock
      vsock_remove_sock
        vsock_remove_bound
  release

Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during
socket destruction.

unreferenced object 0xffff888109e3f800 (size 2040):
  comm "kworker/5:2", pid 371, jiffies 4294940105
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00  (..@............
  backtrace (crc 9e5f4e84):
    [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360
    [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120
    [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0
    [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310
    [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0
    [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140
    [<ffffffff810fc6ac>] process_one_work+0x20c/0x570
    [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0
    [<ffffffff811070dd>] kthread+0xdd/0x110
    [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50
    [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30


Affected upstream versions: 5.9.13 < 5.10, 5.10
Fixed upstream versions: 0, 5.10, 5.10.232, 5.15.175, 6.1.119, 6.11.10, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c
CVE-2024-53120: kernel: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-12-02T00:00:00+00:00

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

net/mlx5e: CT: Fix null-ptr-deref in add rule err flow

In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()
callback returns error, zone_rule->attr is used uninitiated. Fix it to
use attr which has the needed pointer value.

Kernel log:
 BUG: kernel NULL pointer dereference, address: 0000000000000110
 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]
…
 Call Trace:
  <TASK>
  ? __die+0x20/0x70
  ? page_fault_oops+0x150/0x3e0
  ? exc_page_fault+0x74/0x140
  ? asm_exc_page_fault+0x22/0x30
  ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]
  ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core]
  mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core]
  ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]
  nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table]
  flow_offload_work_handler+0x142/0x320 [nf_flow_table]
  ? finish_task_switch.isra.0+0x15b/0x2b0
  process_one_work+0x16c/0x320
  worker_thread+0x28c/0x3a0
  ? __pfx_worker_thread+0x10/0x10
  kthread+0xb8/0xf0
  ? __pfx_kthread+0x10/0x10
  ret_from_fork+0x2d/0x50
  ? __pfx_kthread+0x10/0x10
  ret_from_fork_asm+0x1a/0x30
  </TASK>


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.174, 6.1.119, 6.11.10, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 882f392d9e3649557e71efd78ae20c86039ffb7c
CVE-2024-53122: kernel: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust
Component: kernel
Severity: Moderate
CWE: CWE-369 (Divide By Zero)
CVSS v3: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-12-02T00:00:00+00:00

A divide by zero flaw was found in the Linux kernel's Multipath TCP (MPTCP). This issue could allow a remote user to crash the system.

Statement: By default, the MPTCP support is disabled in RHEL. This bug is only applicable if enabled.

Affected upstream versions: 5.10
Fixed upstream versions: 0, 5.15.174, 6.1.119, 6.11.10, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0a9a182ea5c7bb0374e527130fd85024ace7279b
CVE-2024-53134: kernel: pmdomain: imx93-blk-ctrl: correct remove path
Component: kernel
Severity: Moderate
CWE: CWE-670 (Always-Incorrect Control Flow Implementation)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-12-04T00:00:00+00:00

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

pmdomain: imx93-blk-ctrl: correct remove path

The check condition should be 'i < bc->onecell_data.num_domains', not
'bc->onecell_data.num_domains' which will make the look never finish
and cause kernel panic.

Also disable runtime to address
"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"


Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.11.10, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8fc228ab5d38a026eae7183a5f74a4fac43d9b6a
CVE-2024-53135: kernel: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 6.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H)
Public date: 2024-12-04T00:00:00+00:00

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

KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN

Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support
for virtualizing Intel PT via guest/host mode unless BROKEN=y.  There are
myriad bugs in the implementation, some of which are fatal to the guest,
and others which put the stability and health of the host at risk.

For guest fatalities, the most glaring issue is that KVM fails to ensure
tracing is disabled, and *stays* disabled prior to VM-Enter, which is
necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing
is enabled (enforced via a VMX consistency check).  Per the SDM:

  If the logical processor is operating with Intel PT enabled (if
  IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load
  IA32_RTIT_CTL" VM-entry control must be 0.

On the host side, KVM doesn't validate the guest CPUID configuration
provided by userspace, and even worse, uses the guest configuration to
decide what MSRs to save/load at VM-Enter and VM-Exit.  E.g. configuring
guest CPUID to enumerate more address ranges than are supported in hardware
will result in KVM trying to passthrough, save, and load non-existent MSRs,
which generates a variety of WARNs, ToPA ERRORs in the host, a potential
deadlock, etc.


Affected upstream versions: 5.0
Fixed upstream versions: 0, 5.10.231, 5.15.174, 5.4.287, 6.1.119, 6.11.10, 6.12, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c3742319d021f5aa3a0a8c828485fee14753f6de
CVE-2024-53136: kernel: mm: revert "mm: shmem: fix data-race in shmem_getattr()"
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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: 2024-12-04T00:00:00+00:00

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

mm: revert "mm: shmem: fix data-race in shmem_getattr()"

Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as
suggested by Chuck [1].  It is causing deadlocks when accessing tmpfs over
NFS.

As Hugh commented, "added just to silence a syzbot sanitizer splat: added
where there has never been any practical problem".


Affected upstream versions: 4.19.323 < 4.19.325, 5.4.285 < 5.4.287, 5.10.229 < 5.10.231, 5.15.171 < 5.15.174, 6.1.116 < 6.1.119, 6.6.60 < 6.6.63, 6.11.7 < 6.11.10
Fixed upstream versions: 4.19.325, 5.10.231, 5.15.174, 5.4.287, 6.1.119, 6.11.10, 6.6.63
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 36b537e8f302f670c7cf35d88a3a294443e32d52
CVE-2024-53141: kernel: netfilter: ipset: add missing range check in bitmap_ip_uadt
Component: kernel
Severity: Important
CWE: CWE-20 (Improper Input Validation)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-12-06T00:00:00+00:00

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

netfilter: ipset: add missing range check in bitmap_ip_uadt

When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists,
the values of ip and ip_to are slightly swapped. Therefore, the range check
for ip should be done later, but this part is missing and it seems that the
vulnerability occurs.

So we should add missing range checks and remove unnecessary range checks.

Statement: For the Red Hat Enterprise Linux 9, the vulnerability fixed starting from the 9.6 version.

The attack complexity is High, because existing reproducer doesn't work for Red Hat Enterprise Linux 8 (any version) or Fedora (latest version) or Red Hat Enterprise Linux 9 (latest version). It would require some complex tuning before potentially could be used with the Red Hat Enterprise Linux 8. For the Red Hat Enterprise Linux 8 please use mitigation and for Red Hat Enterprise Linux 9 (or Fedora) update to latest version.

Only local users with `CAP_NET_ADMIN` capability or root can trigger this issue. 
On Red Hat Enterprise Linux, local unprivileged users can exploit unprivileged user namespaces (CONFIG_USER_NS) to grant themselves this capability.

The OpenShift Container Platform (OCP) control planes or master machines are based on Red Hat Enterprise Linux CoreOS (RHCOS) that consists primarily of RHEL components, therefore, it is also affected by this kernel vulnerability. A successful exploit needs necessary privileges (CAP_NET_ADMIN) and direct, local access. A local user in RHCOS is already a root with full permissions, hence existence of this vulnerability does not bring any value from the potential attacker perspective. From the OpenShift containers perspective, this vulnerability cannot be exploited as in OpenShift the cluster processes on the node are namespaced, which means that switching the namespace in the running OpenShift container will not bring necessary capabilities.
This means that for OpenShift, the impact of this vulnerability is Low.

Similar to the CVE-2023-32233 vulnerability, this has been explained in the following blog post as an example of a "Container escape vulnerability":
https://www.redhat.com/en/blog/containers-vulnerability-risk-assessment

Affected upstream versions: 2.6.39
Fixed upstream versions: 0, 4.19.325, 5.10.231, 5.15.174, 5.4.287, 6.1.120, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3c20b5948f119ae61ee35ad8584d666020c91581
CVE-2024-53146: kernel: NFSD: Prevent a potential integer overflow
Component: kernel
Severity: Moderate
CWE: CWE-190 (Integer Overflow or Wraparound)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-12-24T00:00:00+00:00

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

NFSD: Prevent a potential integer overflow

If the tag length is >= U32_MAX - 3 then the "length + 4" addition
can result in an integer overflow. Address this by splitting the
decoding into several steps so that decode_cb_compound4res() does
not have to perform arithmetic on the unsafe length value.


Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.19.325, 5.10.231, 5.15.174, 5.4.287, 6.1.120, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 745f7ce5a95e783ba62fe774325829466aec2aa8
CVE-2024-53147: kernel: exfat: fix out-of-bounds access of directory entries
Component: kernel
Severity: Moderate
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
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: 2024-12-24T00:00:00+00:00

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

exfat: fix out-of-bounds access of directory entries

In the case of the directory size is greater than or equal to
the cluster size, if start_clu becomes an EOF cluster(an invalid
cluster) due to file system corruption, then the directory entry
where ei->hint_femp.eidx hint is outside the directory, resulting
in an out-of-bounds access, which may cause further file system
corruption.

This commit adds a check for start_clu, if it is an invalid cluster,
the file or directory will be treated as empty.

Statement: Actual only for latest Red Hat Enterprise Linux 9, because before configuration parameter for exFAT file system (CONFIG_EXFAT_FS) was disabled. The bug could happen if file system already corrupted and leads to potentially more corruptions.

Affected upstream versions: 5.7
Fixed upstream versions: 0, 6.11.11, 6.12.2, 6.13
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a0120d6463368378539ef928cf067d02372efb8c
CVE-2024-53150: kernel: ALSA: usb-audio: Fix out of bounds reads when finding clock sources
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: 2024-12-24T00:00:00+00:00

A vulnerability was found in the Linux kernel's USB Audio driver. This flaw can allow an attacker with physical access to the system to use a malicious USB device to gain additional access. This is possible by reading arbitrary system memory.


Affected upstream versions: 4.19.84 < 4.20, 5.3.11 < 5.4, 5.4
Fixed upstream versions: 0, 4.20, 5.10.231, 5.15.174, 5.4, 5.4.287, 6.1.120, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a632bdcb359fd8145e86486ff8612da98e239acd
CVE-2024-53152: kernel: PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()
Component: kernel
Severity: Moderate
CVSS v3: 6.4 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-12-24T00:00:00+00:00

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

PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()

Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.

All of the tegra194 endpoint SoCs supported as of now depend on the refclk
from the host for keeping the controller operational. Due to this
limitation, any access to the hardware registers in the absence of refclk
will result in a whole endpoint crash. Unfortunately, most of the
controller cleanups require accessing the hardware registers (like eDMA
cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup
functions can cause the crash in the endpoint SoC once host asserts PERST#.

One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host.

Thus, fix this crash by moving the controller cleanups to the start of
the pex_ep_event_pex_rst_deassert() function. This function is called
whenever the host has deasserted PERST# and it is guaranteed that the
refclk would be active at this point. So at the start of this function
(after enabling resources) the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.

Statement: The affected source code not introduced yet in Red Hat Enterprise Linux. The bug happens during cleanup, so the security impact is limited.

Affected upstream versions: 6.10
Fixed upstream versions: 0, 6.11.11, 6.12.2, 6.13
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 70212c2300971506e986d95000d2745529cac9d7
CVE-2024-53156: kernel: wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()
Component: kernel
Severity: Moderate
CWE: CWE-129 (Improper Validation of Array Index)
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: 2024-12-24T00:00:00+00:00

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

wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()

I found the following bug in my fuzzer:

  UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51
  index 255 is out of range for type 'htc_endpoint [22]'
  CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  Workqueue: events request_firmware_work_func
  Call Trace:
   <TASK>
   dump_stack_lvl+0x180/0x1b0
   __ubsan_handle_out_of_bounds+0xd4/0x130
   htc_issue_send.constprop.0+0x20c/0x230
   ? _raw_spin_unlock_irqrestore+0x3c/0x70
   ath9k_wmi_cmd+0x41d/0x610
   ? mark_held_locks+0x9f/0xe0
   ...

Since this bug has been confirmed to be caused by insufficient verification
of conn_rsp_epid, I think it would be appropriate to add a range check for
conn_rsp_epid to htc_connect_service() to prevent the bug from occurring.


Affected upstream versions: 2.6.35
Fixed upstream versions: 0, 4.19.325, 5.10.231, 5.15.174, 5.4.287, 6.1.120, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5f177fb9d01355ac183e65ad8909ea8ef734e0cf
CVE-2024-53160: kernel: rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
CVSS v3: 6.3 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-12-24T00:00:00+00:00

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

rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu

KCSAN reports a data race when access the krcp->monitor_work.timer.expires
variable in the schedule_delayed_monitor_work() function:

<snip>
BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu

read to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:
 schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline]
 kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839
 trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441
 bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203
 generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849
 bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143
 __sys_bpf+0x2e5/0x7a0
 __do_sys_bpf kernel/bpf/syscall.c:5741 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5739 [inline]
 __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739
 x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

write to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0:
 __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173
 add_timer_global+0x51/0x70 kernel/time/timer.c:1330
 __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523
 queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552
 queue_delayed_work include/linux/workqueue.h:677 [inline]
 schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline]
 kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643
 process_one_work kernel/workqueue.c:3229 [inline]
 process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310
 worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391
 kthread+0x1d1/0x210 kernel/kthread.c:389
 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: events_unbound kfree_rcu_monitor
<snip>

kfree_rcu_monitor() rearms the work if a "krcp" has to be still
offloaded and this is done without holding krcp->lock, whereas
the kvfree_call_rcu() holds it.

Fix it by acquiring the "krcp->lock" for kfree_rcu_monitor() so
both functions do not race anymore.


Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 967a0e61910825d1fad009d836a6cb41f7402395
CVE-2024-53161: kernel: EDAC/bluefield: Fix potential integer overflow
Component: kernel
Severity: Low
CWE: CWE-190 (Integer Overflow or Wraparound)
CVSS v3: 3.8 (CVSS:3.1/AV:P/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-12-24T00:00:00+00:00

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

EDAC/bluefield: Fix potential integer overflow

The 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idx
left-shifted 16 bits and OR-ed with DIMM index.  With mem_ctrl_idx defined as
32-bits wide the left-shift operation truncates the upper 16 bits of
information during the calculation of the SMC argument.

The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any
potential integer overflow, i.e. loss of data from upper 16 bits.

Statement: Actual only for latest version of Red Hat Enterprise Linux 8 and latest version of Red Hat Enterprise Linux 9 (where configuration parameter CONFIG_EDAC_BLUEFIELD enabled as module). For triggering this bug need physical access (kind of insert malicious DIMM of memory), because it can happen only during boot or after DIMM of memory updated. Could happen only if this type of memory being used: "Mellanox BlueField SoC". The security impact is limited.

Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.231, 5.15.174, 5.4.287, 6.1.120, 6.11.11, 6.12.2, 6.13, 6.6.64
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8cc31cfa36ff37aff399b72faa2ded58110112ae