huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-49353: kernel: powerpc/papr_scm: don't requests stats with '0' sized stats buffer
Component: kernel
Severity: Low
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: 2025-02-26T00:00:00+00:00

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

powerpc/papr_scm: don't requests stats with '0' sized stats buffer

Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being
reported with vPMEM when papr_scm probe is being called. The panic is of the
form below and is observed only with following option disabled(profile) for the
said LPAR 'Enable Performance Information Collection' in the HMC:

 Kernel attempted to write user page (1c) - exploit attempt? (uid: 0)
 BUG: Kernel NULL pointer dereference on write at 0x0000001c
 Faulting instruction address: 0xc008000001b90844
 Oops: Kernel access of bad area, sig: 11 [#1]
<snip>
 NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm]
 LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm]
 Call Trace:
       0xc00000000941bca0 (unreliable)
       papr_scm_probe+0x2ac/0x6ec [papr_scm]
       platform_probe+0x98/0x150
       really_probe+0xfc/0x510
       __driver_probe_device+0x17c/0x230
<snip>
 ---[ end trace 0000000000000000 ]---
 Kernel panic - not syncing: Fatal exception

On investigation looks like this panic was caused due to a 'stat_buffer' of
size==0 being provided to drc_pmem_query_stats() to fetch all performance
stats-ids of an NVDIMM. However drc_pmem_query_stats() shouldn't have been called
since the vPMEM NVDIMM doesn't support and performance stat-id's. This was caused
due to missing check for 'p->stat_buffer_len' at the beginning of
papr_scm_pmu_check_events() which indicates that the NVDIMM doesn't support
performance-stats.

Fix this by introducing the check for 'p->stat_buffer_len' at the beginning of
papr_scm_pmu_check_events().

[1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com


Affected upstream versions: 5.18.3 < 5.18.4
Fixed upstream versions: 5.18.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e1295aab2ebcda1c1a9ed342baedc080e5c393e5
CVE-2022-49356: kernel: SUNRPC: Trap RDMA segment overflows
Component: kernel
Severity: Moderate
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: 2025-02-26T00:00:00+00:00

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

SUNRPC: Trap RDMA segment overflows

Prevent svc_rdma_build_writes() from walking off the end of a Write
chunk's segment array. Caught with KASAN.

The test that this fix replaces is invalid, and might have been left
over from an earlier prototype of the PCL work.


Affected upstream versions: 5.11
Fixed upstream versions: 0, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ea26bf5eca1459b5a7824997d7823409ce38214e
CVE-2022-49357: kernel: efi: Do not import certificates from UEFI Secure Boot for T2 Macs
Component: kernel
Severity: Moderate
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

efi: Do not import certificates from UEFI Secure Boot for T2 Macs

On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables
at early boot to load UEFI Secure Boot certificates, a page fault occurs
in Apple firmware code and EFI runtime services are disabled with the
following logs:

[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000
WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0
(Removed some logs from here)
Call Trace:
 <TASK>
 page_fault_oops+0x4f/0x2c0
 ? search_bpf_extables+0x6b/0x80
 ? search_module_extables+0x50/0x80
 ? search_exception_tables+0x5b/0x60
 kernelmode_fixup_or_oops+0x9e/0x110
 __bad_area_nosemaphore+0x155/0x190
 bad_area_nosemaphore+0x16/0x20
 do_kern_addr_fault+0x8c/0xa0
 exc_page_fault+0xd8/0x180
 asm_exc_page_fault+0x1e/0x30
(Removed some logs from here)
 ? __efi_call+0x28/0x30
 ? switch_mm+0x20/0x30
 ? efi_call_rts+0x19a/0x8e0
 ? process_one_work+0x222/0x3f0
 ? worker_thread+0x4a/0x3d0
 ? kthread+0x17a/0x1a0
 ? process_one_work+0x3f0/0x3f0
 ? set_kthread_struct+0x40/0x40
 ? ret_from_fork+0x22/0x30
 </TASK>
---[ end trace 1f82023595a5927f ]---
efi: Froze efi_rts_wq and disabled EFI Runtime Services
integrity: Couldn't get size: 0x8000000000000015
integrity: MODSIGN: Couldn't get UEFI db list
efi: EFI Runtime Services are disabled!
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get UEFI dbx list
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get mokx list
integrity: Couldn't get size: 0x80000000

So we avoid reading these UEFI variables and thus prevent the crash.


Affected upstream versions: 5.0
Fixed upstream versions: 0, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b1cda6dd2c44771f042d65f0d17bec322ef99a0a
CVE-2022-49362: kernel: NFSD: Fix potential use-after-free in nfsd_file_put()
Component: kernel
Severity: Important
CWE: CWE-416 (Use After Free)
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-02-26T00:00:00+00:00

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

NFSD: Fix potential use-after-free in nfsd_file_put()

nfsd_file_put_noref() can free @nf, so don't dereference @nf
immediately upon return from nfsd_file_put_noref().


Affected upstream versions: 5.18
Fixed upstream versions: 0, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ada1757b259f353cade47037ee0a0249b4cddad3
CVE-2022-49365: kernel: drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq()
Component: kernel
Severity: Moderate
CWE: CWE-193 (Off-by-one Error)
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: 2025-02-26T00:00:00+00:00

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

drm/amdgpu: Off by one in dm_dmub_outbox1_low_irq()

The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds
access.


Affected upstream versions: 5.16
Fixed upstream versions: 0, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ec9ec3bc08b18c5b1b2feafd306ea7c348013898
CVE-2022-49371: kernel: driver core: fix deadlock in __device_attach
Component: kernel
Severity: Moderate
CWE: CWE-667 (Improper Locking)
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: 2025-02-26T00:00:00+00:00

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

driver core: fix deadlock in __device_attach

In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev)      // get lock dev
  async_schedule_dev(__device_attach_async_helper, dev); // func
    async_schedule_node
      async_schedule_node_domain(func)
        entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
	/* when fail or work limit, sync to execute func, but
	   __device_attach_async_helper will get lock dev as
	   well, which will lead to A-A deadlock.  */
	if (!entry || atomic_read(&entry_count) > MAX_WORK) {
	  func;
	else
	  queue_work_node(node, system_unbound_wq, &entry->work)
  device_unlock(dev)

As shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.

To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.


Affected upstream versions: 4.2
Fixed upstream versions: 0, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 593b595332bd2d65e1a5c1ae7897996c157f5468
CVE-2022-49372: kernel: tcp: tcp_rtx_synack() can be called from process context
Component: kernel
Severity: Moderate
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: 2025-02-26T00:00:00+00:00

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

tcp: tcp_rtx_synack() can be called from process context

Laurent reported the enclosed report [1]

This bug triggers with following coditions:

0) Kernel built with CONFIG_DEBUG_PREEMPT=y

1) A new passive FastOpen TCP socket is created.
   This FO socket waits for an ACK coming from client to be a complete
   ESTABLISHED one.
2) A socket operation on this socket goes through lock_sock()
   release_sock() dance.
3) While the socket is owned by the user in step 2),
   a retransmit of the SYN is received and stored in socket backlog.
4) At release_sock() time, the socket backlog is processed while
   in process context.
5) A SYNACK packet is cooked in response of the SYN retransmit.
6) -> tcp_rtx_synack() is called in process context.

Before blamed commit, tcp_rtx_synack() was always called from BH handler,
from a timer handler.

Fix this by using TCP_INC_STATS() & NET_INC_STATS()
which do not assume caller is in non preemptible context.

[1]
BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180
caller is tcp_rtx_synack.part.0+0x36/0xc0
CPU: 10 PID: 2180 Comm: epollpep Tainted: G           OE     5.16.0-0.bpo.4-amd64 #1  Debian 5.16.12-1~bpo11+1
Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021
Call Trace:
 <TASK>
 dump_stack_lvl+0x48/0x5e
 check_preemption_disabled+0xde/0xe0
 tcp_rtx_synack.part.0+0x36/0xc0
 tcp_rtx_synack+0x8d/0xa0
 ? kmem_cache_alloc+0x2e0/0x3e0
 ? apparmor_file_alloc_security+0x3b/0x1f0
 inet_rtx_syn_ack+0x16/0x30
 tcp_check_req+0x367/0x610
 tcp_rcv_state_process+0x91/0xf60
 ? get_nohz_timer_target+0x18/0x1a0
 ? lock_timer_base+0x61/0x80
 ? preempt_count_add+0x68/0xa0
 tcp_v4_do_rcv+0xbd/0x270
 __release_sock+0x6d/0xb0
 release_sock+0x2b/0x90
 sock_setsockopt+0x138/0x1140
 ? __sys_getsockname+0x7e/0xc0
 ? aa_sk_perm+0x3e/0x1a0
 __sys_setsockopt+0x198/0x1e0
 __x64_sys_setsockopt+0x21/0x30
 do_syscall_64+0x38/0xc0
 entry_SYSCALL_64_after_hwframe+0x44/0xae


Affected upstream versions: 3.7
Fixed upstream versions: 0, 4.14.283, 4.19.247, 4.9.318, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3db889f883e65bbd3b1401279bfc1e9ed255c481
CVE-2022-49374: kernel: tipc: check attribute length for bearer name
Component: kernel
Severity: Low
CWE: CWE-908 (Use of Uninitialized Resource)
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: 2025-02-26T00:00:00+00:00

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

tipc: check attribute length for bearer name

syzbot reported uninit-value:
=====================================================
BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]
BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725
 string_nocheck lib/vsprintf.c:644 [inline]
 string+0x4f9/0x6f0 lib/vsprintf.c:725
 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806
 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158
 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256
 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283
 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50
 _printk+0x18d/0x1cf kernel/printk/printk.c:2293
 tipc_enable_bearer net/tipc/bearer.c:371 [inline]
 __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033
 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042
 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]

- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.
- Do not use 'illegal name' in printing message.


Affected upstream versions: 4.17
Fixed upstream versions: 0, 4.19.247, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f07670871f4d19e613740eebe210e7e9ea535973
CVE-2022-49376: kernel: scsi: sd: Fix potential NULL pointer dereference
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
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: 2025-02-26T00:00:00+00:00

A flaw was found in the Linux kernel's SCSI subsystem. A NULL pointer dereference can be triggered when an error occurs before the sdkp->device object is fully initialized, causing a system crash and a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.8 and 9.2 via RHSA-2023:2951 [1] and RHSA-2023:2458 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2023:2951

[2]. https://access.redhat.com/errata/RHSA-2023:2458

Affected upstream versions: 4.10
Fixed upstream versions: 0, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c1f0187025905e9981000d44a92e159468b561a8
CVE-2022-49377: kernel: blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx
Component: kernel
Severity: Moderate
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-02-26T00:00:00+00:00

A use-after-free vulnerability was found in the blk_mq_get_sq_hctx function in the Linux kernel's block multiqueue (blk-mq) subsystem. This issue occurs when the function accesses the tagset pointer to determine the current default hardware context through mapping. If this access occurs after the tagset has been freed, typically after the queue cleanup process, it can lead to memory corruption. Such corruption may result in system crashes, information leaks, or privilege escalation, depending on how the freed memory is subsequently used.


Affected upstream versions: 5.12
Fixed upstream versions: 0, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 460aa288c5cd0544dcf933a2f0ad0e8c6d2d35ff
CVE-2022-49378: kernel: sfc: fix considering that all channels have TX queues
Component: kernel
Severity: Moderate
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: 2025-02-26T00:00:00+00:00

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

sfc: fix considering that all channels have TX queues

Normally, all channels have RX and TX queues, but this is not true if
modparam efx_separate_tx_channels=1 is used. In that cases, some
channels only have RX queues and others only TX queues (or more
preciselly, they have them allocated, but not initialized).

Fix efx_channel_has_tx_queues to return the correct value for this case
too.

Messages shown at probe time before the fix:
 sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0
 ------------[ cut here ]------------
 netdevice: ens6f0np0: failed to initialise TXQ -1
 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]
 [...] stripped
 RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]
 [...] stripped
 Call Trace:
  efx_init_tx_queue+0xaa/0xf0 [sfc]
  efx_start_channels+0x49/0x120 [sfc]
  efx_start_all+0x1f8/0x430 [sfc]
  efx_net_open+0x5a/0xe0 [sfc]
  __dev_open+0xd0/0x190
  __dev_change_flags+0x1b3/0x220
  dev_change_flags+0x21/0x60
 [...] stripped

Messages shown at remove time before the fix:
 sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues
 sfc 0000:03:00.0 ens6f0np0: failed to flush queues


Affected upstream versions: 5.5
Fixed upstream versions: 0, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8f81a4113e1e574d2cbde4f2cd599380a9189c0f
CVE-2022-49379: kernel: driver core: Fix wait_for_device_probe() &#38; deferred_probe_timeout interaction
Component: kernel
Severity: Moderate
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: 2025-02-26T00:00:00+00:00

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

driver core: Fix wait_for_device_probe() & deferred_probe_timeout interaction

Mounting NFS rootfs was timing out when deferred_probe_timeout was
non-zero [1].  This was because ip_auto_config() initcall times out
waiting for the network interfaces to show up when
deferred_probe_timeout was non-zero. While ip_auto_config() calls
wait_for_device_probe() to make sure any currently running deferred
probe work or asynchronous probe finishes, that wasn't sufficient to
account for devices being deferred until deferred_probe_timeout.

Commit 35a672363ab3 ("driver core: Ensure wait_for_device_probe() waits
until the deferred_probe_timeout fires") tried to fix that by making
sure wait_for_device_probe() waits for deferred_probe_timeout to expire
before returning.

However, if wait_for_device_probe() is called from the kernel_init()
context:

- Before deferred_probe_initcall() [2], it causes the boot process to
  hang due to a deadlock.

- After deferred_probe_initcall() [3], it blocks kernel_init() from
  continuing till deferred_probe_timeout expires and beats the point of
  deferred_probe_timeout that's trying to wait for userspace to load
  modules.

Neither of this is good. So revert the changes to
wait_for_device_probe().

[1] - https://lore.kernel.org/lkml/TYAPR01MB45443DF63B9EF29054F7C41FD8C60@TYAPR01MB4544.jpnprd01.prod.outlook.com/
[2] - https://lore.kernel.org/lkml/YowHNo4sBjr9ijZr@dev-arch.thelio-3990X/
[3] - https://lore.kernel.org/lkml/Yo3WvGnNk3LvLb7R@linutronix.de/


Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 71cbce75031aed26c72c2dc8a83111d181685f1b
CVE-2022-49385: kernel: driver: base: fix UAF when driver_attach failed
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

A flaw was discovered in the Linux kernel’s device driver core. When driver_attach(drv) fails, the associated driver_private structure is freed—but the driver remains registered on the bus. This leads to a use-after-free condition when the kernel subsequently references the freed driver_private. A local, authenticated user with low privileges can trigger this flaw to cause memory corruption, system instability, or denial of service.


Affected upstream versions: 3.9
Fixed upstream versions: 0, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5d709f58c743166fe1c6914b9de0ae8868600d9b
CVE-2022-49389: kernel: usb: usbip: fix a refcount leak in stub_probe()
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
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: 2025-02-26T00:00:00+00:00

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

usb: usbip: fix a refcount leak in stub_probe()

usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails
after that, usb_put_dev() needs to be called to release the reference.

Fix this by moving usb_put_dev() to sdev_free error path handling.

Find this by code review.


Affected upstream versions: 3.16.58 < 3.17, 3.18.110 < 3.19, 3.19
Fixed upstream versions: 0, 3.17, 3.19, 4.14.283, 4.19.247, 4.9.318, 5.10.122, 5.15.47, 5.17.15, 5.18.4, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6bafee2f18af5e5ac125e42960bc65496d0e56a0
CVE-2022-49395: kernel: um: Fix out-of-bounds read in LDT setup
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

A vulnerability was found in the Linux kernel's user mode (um) subsystem, specifically within the Local Descriptor Table (LDT) setup functionality. The issue arises from the syscall_stub_data() function misinterpreting the data_count parameter as a byte count rather than a count of longs, leading to an out-of-bounds read. This flaw could expose sensitive kernel memory and cause system instability.


Affected upstream versions: 2.6.15
Fixed upstream versions: 0, 4.14.283, 4.19.247, 4.9.318, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 668ca34a428d6ffc0f99a1a6a9b661a288d4183b
CVE-2022-49398: kernel: usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback
Component: kernel
Severity: Moderate
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: 2025-02-26T00:00:00+00:00

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

usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback

The list_for_each_entry_safe() macro saves the current item (n) and
the item after (n+1), so that n can be safely removed without
corrupting the list.  However, when traversing the list and removing
items using gadget giveback, the DWC3 lock is briefly released,
allowing other routines to execute.  There is a situation where, while
items are being removed from the cancelled_list using
dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable
routine is running in parallel (due to UDC unbind).  As the cleanup
routine removes n, and the pullup disable removes n+1, once the
cleanup retakes the DWC3 lock, it references a request who was already
removed/handled.  With list debug enabled, this leads to a panic.
Ensure all instances of the macro are replaced where gadget giveback
is used.

Example call stack:

Thread#1:
__dwc3_gadget_ep_set_halt() - CLEAR HALT
  -> dwc3_gadget_ep_cleanup_cancelled_requests()
    ->list_for_each_entry_safe()
    ->dwc3_gadget_giveback(n)
      ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]
      ->spin_unlock
      ->Thread#2 executes
      ...
    ->dwc3_gadget_giveback(n+1)
      ->Already removed!

Thread#2:
dwc3_gadget_pullup()
  ->waiting for dwc3 spin_lock
  ...
  ->Thread#1 released lock
  ->dwc3_stop_active_transfers()
    ->dwc3_remove_requests()
      ->fetches n+1 item from cancelled_list (n removed by Thread#1)
      ->dwc3_gadget_giveback()
        ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list]
        ->spin_unlock


Affected upstream versions: 4.19.57 < 4.20, 5.0
Fixed upstream versions: 0, 4.20, 5.15.47, 5.17.15, 5.18.4, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1c6e5dc3b639c96e6839a8d1b8e951923fdfd34a
CVE-2022-49404: kernel: RDMA/hfi1: Fix potential integer multiplication overflow errors
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: 2025-02-26T00:00:00+00:00

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

RDMA/hfi1: Fix potential integer multiplication overflow errors

When multiplying of different types, an overflow is possible even when
storing the result in a larger type. This is because the conversion is
done after the multiplication. So arithmetic overflow and thus in
incorrect value is possible.

Correct an instance of this in the inter packet delay calculation.  Fix by
ensuring one of the operands is u64 which will promote the other to u64 as
well ensuring no overflow.


Affected upstream versions: 4.3
Fixed upstream versions: 0, 4.14.283, 4.19.247, 4.9.318, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a