vdanen/rhvex-cve huggingface dataset:
CVE-2024-50147 (Moderate severity, published 2024-11-06)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix command bitmask initialization

Command bitmask have a dedicated bit for MANAGE_PAGES command, this bit
isn't Initialize during command bitmask Initialization, only during
MANAGE_PAGES.

In addition, mlx5_cmd_trigger_completions() is trying to trigger
completion for MANAGE_PAGES command as well.

Hence, in case health error occurred before any MANAGE_PAGES command
have been invoke (for example, during mlx5_enable_hca()),
mlx5_cmd_trigger_completions() will try to trigger completion for
MANAGE_PAGES command, which will result in null-ptr-deref error.[1]

Fix it by Initialize command bitmask correctly.

While at it, re-write the code for better understanding.

[1]
BUG: KASAN: null-ptr-deref in mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]
Write of size 4 at addr 0000000000000214 by task kworker/u96:2/12078
CPU: 10 PID: 12078 Comm: kworker/u96:2 Not tainted 6.9.0-rc2_for_upstream_debug_2024_04_07_19_01 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Workqueue: mlx5_health0000:08:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]
Call Trace:
 <TASK>
 dump_stack_lvl+0x7e/0xc0
 kasan_report+0xb9/0xf0
 kasan_check_range+0xec/0x190
 mlx5_cmd_trigger_completions+0x1db/0x600 [mlx5_core]
 mlx5_cmd_flush+0x94/0x240 [mlx5_core]
 enter_error_state+0x6c/0xd0 [mlx5_core]
 mlx5_fw_fatal_reporter_err_work+0xf3/0x480 [mlx5_core]
 process_one_work+0x787/0x1490
 ? lockdep_hardirqs_on_prepare+0x400/0x400
 ? pwq_dec_nr_in_flight+0xda0/0xda0
 ? assign_work+0x168/0x240
 worker_thread+0x586/0xd30
 ? rescuer_thread+0xae0/0xae0
 kthread+0x2df/0x3b0
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork+0x2d/0x70
 ? kthread_complete_and_exit+0x20/0x20
 ret_from_fork_asm+0x11/0x20
 </TASK>
CVE-2024-35944 (Low severity, published 2024-05-18)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()

Syzkaller hit 'WARNING in dg_dispatch_as_host' bug.

memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg"
at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)

WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237
dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237

Some code commentry, based on my understanding:

544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size)
/// This is 24 + payload_size

memcpy(&dg_info->msg, dg, dg_size);
	Destination = dg_info->msg ---> this is a 24 byte
					structure(struct vmci_datagram)
	Source = dg --> this is a 24 byte structure (struct vmci_datagram)
	Size = dg_size = 24 + payload_size

{payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.

 35 struct delayed_datagram_info {
 36         struct datagram_entry *entry;
 37         struct work_struct work;
 38         bool in_dg_host_queue;
 39         /* msg and msg_payload must be together. */
 40         struct vmci_datagram msg;
 41         u8 msg_payload[];
 42 };

So those extra bytes of payload are copied into msg_payload[], a run time
warning is seen while fuzzing with Syzkaller.

One possible way to fix the warning is to split the memcpy() into
two parts -- one -- direct assignment of msg and second taking care of payload.

Gustavo quoted:
"Under FORTIFY_SOURCE we should not copy data across multiple members
in a structure."
CVE-2024-40794 (Important severity, published 2024-07-28)
CVSS score: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N)
Description: This issue was addressed through improved state management. This issue is fixed in macOS Sonoma 14.6, iOS 17.6 and iPadOS 17.6, Safari 17.6. Private Browsing tabs may be accessed without authentication.
Statement: There's no supported Red Hat product affected by this issue, as the version of WebKitGTK shipped with any of them contains the vulnerable code path.
CVE-2024-42253 (Low severity, published 2024-08-07)
CVSS score: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-667
Description: In the Linux kernel, the following vulnerability has been resolved:

gpio: pca953x: fix pca953x_irq_bus_sync_unlock race

Ensure that `i2c_lock' is held when setting interrupt latch and mask in
pca953x_irq_bus_sync_unlock() in order to avoid races.

The other (non-probe) call site pca953x_gpio_set_multiple() ensures the
lock is held before calling pca953x_write_regs().

The problem occurred when a request raced against irq_bus_sync_unlock()
approximately once per thousand reboots on an i.MX8MP based system.

 * Normal case

   0-0022: write register AI|3a {03,02,00,00,01} Input latch P0
   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
   0-0022: write register AI|08 {ff,00,00,00,00} Output P3
   0-0022: write register AI|12 {fc,00,00,00,00} Config P3

 * Race case

   0-0022: write register AI|08 {ff,00,00,00,00} Output P3
   0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register ***
   0-0022: write register AI|12 {fc,00,00,00,00} Config P3
   0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0
CVE-2024-56640 (Moderate severity, published 2024-12-26)
CVSS score: 6.4 (CVSS:3.1/AV:A/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
CWE: CWE-416
Description: In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix LGR and link use-after-free issue

We encountered a LGR/link use-after-free issue, which manifested as
the LGR/link refcnt reaching 0 early and entering the clear process,
making resource access unsafe.

 refcount_t: addition on 0; use-after-free.
 WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140
 Workqueue: events smc_lgr_terminate_work [smc]
 Call trace:
  refcount_warn_saturate+0x9c/0x140
  __smc_lgr_terminate.part.45+0x2a8/0x370 [smc]
  smc_lgr_terminate_work+0x28/0x30 [smc]
  process_one_work+0x1b8/0x420
  worker_thread+0x158/0x510
  kthread+0x114/0x118

or

 refcount_t: underflow; use-after-free.
 WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140
 Workqueue: smc_hs_wq smc_listen_work [smc]
 Call trace:
  refcount_warn_saturate+0xf0/0x140
  smcr_link_put+0x1cc/0x1d8 [smc]
  smc_conn_free+0x110/0x1b0 [smc]
  smc_conn_abort+0x50/0x60 [smc]
  smc_listen_find_device+0x75c/0x790 [smc]
  smc_listen_work+0x368/0x8a0 [smc]
  process_one_work+0x1b8/0x420
  worker_thread+0x158/0x510
  kthread+0x114/0x118

It is caused by repeated release of LGR/link refcnt. One suspect is that
smc_conn_free() is called repeatedly because some smc_conn_free() from
server listening path are not protected by sock lock.

e.g.

Calls under socklock        | smc_listen_work
-------------------------------------------------------
lock_sock(sk)               | smc_conn_abort
smc_conn_free               | \- smc_conn_free
\- smcr_link_put            |    \- smcr_link_put (duplicated)
release_sock(sk)

So here add sock lock protection in smc_listen_work() path, making it
exclusive with other connection operations.
Mitigation: To mitigate this issue, prevent module smc from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
CVE-2024-37353 (Low severity, published 2024-06-20)
CVSS score: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-415
Description: [REJECTED CVE] A resource management issue exists in the Linux Kernel's virtio module. When request_irq() fails in vp_find_vqs_msix(), the cleanup path incorrectly attempts to free an already released IRQ, resulting in warnings and potential system instability. This issue arises from the mishandling of virtual queue deletion during error handling.
Statement: This CVE has been rejected upstream:
https://lore.kernel.org/linux-cve-announce/2024082213-REJECTED-915e@gregkh/T/#u

Red Hat has also evaluated this issue and determined that it does not meet the criteria to be classified as a security vulnerability. This assessment is based on the issue not posing a significant security risk, being a result of misconfiguration or usage error, or falling outside the scope of security considerations. 

As such, this CVE has been marked as "Rejected" in alignment with Red Hat's vulnerability management policies.

If you have additional information or concerns regarding this determination, please contact Red Hat Product Security for further clarification.
CVE-2024-57952 (Low severity, published 2025-02-11)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-20
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "libfs: fix infinite directory reads for offset dir"

The current directory offset allocator (based on mtree_alloc_cyclic)
stores the next offset value to return in octx->next_offset. This
mechanism typically returns values that increase monotonically over
time. Eventually, though, the newly allocated offset value wraps
back to a low number (say, 2) which is smaller than other already-
allocated offset values.

Yu Kuai <yukuai3@huawei.com> reports that, after commit 64a7ce76fb90
("libfs: fix infinite directory reads for offset dir"), if a
directory's offset allocator wraps, existing entries are no longer
visible via readdir/getdents because offset_readdir() stops listing
entries once an entry's offset is larger than octx->next_offset.
These entries vanish persistently -- they can be looked up, but will
never again appear in readdir(3) output.

The reason for this is that the commit treats directory offsets as
monotonically increasing integer values rather than opaque cookies,
and introduces this comparison:

	if (dentry2offset(dentry) >= last_index) {

On 64-bit platforms, the directory offset value upper bound is
2^63 - 1. Directory offsets will monotonically increase for millions
of years without wrapping.

On 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator
can wrap after only a few weeks (at worst).

Revert commit 64a7ce76fb90 ("libfs: fix infinite directory reads for
offset dir") to prepare for a fix that can work properly on 32-bit
systems and might apply to recent LTS kernels where shmem employs
the simple_offset mechanism.
CVE-2024-3623 (Important severity, published 2024-04-09)
CVSS score: 8.1 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-256
Description: A flaw was found when using mirror-registry to install Quay. It uses a default database secret key, which is stored in plain-text format in one of the configuration template files. This issue may lead to all instances of Quay deployed using mirror-registry to have the same database secret key. This flaw allows a malicious actor to access sensitive information from Quay's database.
CVE-2024-26811 (Moderate severity, published 2024-04-07)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: validate payload size in ipc response

If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
response to ksmbd kernel server. ksmbd should validate payload size of
ipc response from ksmbd.mountd to avoid memory overrun or
slab-out-of-bounds. This patch validate 3 ipc response that has payload.
CVE-2024-50281 (Low severity, published 2024-11-18)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation

When sealing or unsealing a key blob we currently do not wait for
the AEAD cipher operation to finish and simply return after submitting
the request. If there is some load on the system we can exit before
the cipher operation is done and the buffer we read from/write to
is already removed from the stack. This will e.g. result in NULL
pointer dereference errors in the DCP driver during blob creation.

Fix this by waiting for the AEAD cipher operation to finish before
resuming the seal and unseal calls.
CVE-2024-26954 (Moderate severity, published 2024-04-30)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-125
Description: A flaw was found in the ksmbd module in the Linux kernel. Under some conditions, an out-of-bounds read can occur in the smb_strndup_from_utf16 function, resulting in a denial of service.
Statement: The ksmbd module is not built in the kernel shipped in Red Hat Enterprise Linux, so it is not affected by this vulnerability.
CVE-2024-4109 (None severity, published 2024-12-10)
CVSS score: 0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N)
CWE: CWE-200
Description: [REJECTED CVE] A vulnerability has been identified in the Undertow package where the readHpackString method may incorrectly reuse an HTTP request header value from a previous stream for a new request on the same HTTP/2 connection due to improper handling of the stringBuilder field. While this typically results in an error and connection termination, an attacker could potentially exploit this flaw to leak sensitive information between requests within the same connection.
Statement: Red Hat Product Security does not consider this bug to be a security vulnerability. It has been marked as REJECTED.
CVE-2024-52316 (Low severity, published 2024-11-18)
CVSS score: 7.4 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-248
Description: A flaw was found in Apache Tomcat when configured to use a custom Jakarta Authentication (formerly JASPIC) ServerAuthContext component. This vulnerability allows authentication bypass via improperly handled exceptions during the authentication process.
Statement: Red Hat Product Security has assessed this flaw at Attack Complexity as High, and impact metrics Confidentiality and Integrity as High, with a resultant base flaw Security Impact of Important. However, the factors involved in successful exploitation--usage of a custom Jakarta ServerAuthContext component, possible mishandling of exception management in that custom component, and failure in such a way as to allow a failed authentication to proceed in that exception mishandling--are sufficiently unlikely, such that Apache determined the impact to be Low. While Red Hat concurs with the worst-case assessment of Important for the base flaw, all products are assessed as Low, per individual risk assessment and in concurrence with Apache's rating.

Red Hat Satellite is not directly impacted by this issue as it does not include the affected Tomcat package. However, Tomcat is consumed by Candlepin, a component of Satellite. Red Hat Satellite users are advised to check the impact state of Red Hat Enterprise Linux as any necessary fixes will be distributed through the platform.
CVE-2024-46705 (Low severity, published 2024-09-12)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-119
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe: reset mmio mappings with devm

Set our various mmio mappings to NULL. This should make it easier to
catch something rogue trying to mess with mmio after device removal. For
example, we might unmap everything and then start hitting some mmio
address which has already been unmamped by us and then remapped by
something else, causing all kinds of carnage.
CVE-2024-43854 (Moderate severity, published 2024-08-16)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-401
Description: A flaw was found in the Linux kernel, where it initialized the integrity buffer to zero before writing it to media. Metadata added by bio_integrity_prep uses plain kmalloc, which leads to random kernel memory being written. Protection Information (PI) metadata is limited to the app tag not used by kernel-generated metadata, but for non-PI metadata, the entire buffer leaks kernel memory, potentially exposing sensitive internal kernel data.
Statement: Within regulated environments, a combination of the following controls acts as a significant barrier to successfully exploiting a CWE-401: Missing Release of Memory after Effective Lifetime vulnerability and therefore downgrades the severity of this particular CVE from Moderate to Low.

The platform enforces hardening guidelines to apply the most restrictive configurations necessary for operational requirements. Baseline and configuration setting controls ensure secure system and software configurations, while least functionality reduces the attack surface and minimizes the risk of resource exhaustion from memory leaks. The environment employs malicious code protections such as IDS/IPS and antimalware solutions to detect threats and provide real-time visibility into memory usage, helping prevent memory management issues before they lead to system crashes or exhaustion. 

Event logs are collected and analyzed for correlation, monitoring, alerting, and retention, supporting the detection of abnormal memory usage patterns that may indicate potential leaks. Static code analysis and peer reviews enforce strong input validation and error handling, reducing the risk of input-based denial-of-service (DoS) attacks. 

Finally, memory protection mechanisms such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) are implemented to strengthen defenses against memory allocation vulnerabilities.
Mitigation: Fix this issue by adding the __GFP_ZERO flag to allocations for writes.
CVE-2024-36954 (Low severity, published 2024-05-29)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
CWE: CWE-402
Description: In the Linux kernel, the following vulnerability has been resolved:

tipc: fix a possible memleak in tipc_buf_append

__skb_linearize() doesn't free the skb when it fails, so move
'*buf = NULL' after __skb_linearize(), so that the skb can be
freed on the err path.
CVE-2024-53157 (Low severity, published 2024-12-23)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: arm_scpi: Check the DVFS OPP count returned by the firmware

Fix a kernel crash with the below call trace when the SCPI firmware
returns OPP count of zero.

dvfs_info.opp_count may be zero on some platforms during the reboot
test, and the kernel will crash after dereferencing the pointer to
kcalloc(info->count, sizeof(*opp), GFP_KERNEL).

  |  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
  |  Mem abort info:
  |    ESR = 0x96000004
  |    Exception class = DABT (current EL), IL = 32 bits
  |    SET = 0, FnV = 0
  |    EA = 0, S1PTW = 0
  |  Data abort info:
  |    ISV = 0, ISS = 0x00000004
  |    CM = 0, WnR = 0
  |  user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c
  |  [0000000000000028] pgd=0000000000000000
  |  Internal error: Oops: 96000004 [#1] SMP
  |  scpi-hwmon: probe of PHYT000D:00 failed with error -110
  |  Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c)
  |  CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1
  |  Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS
  |  pstate: 60000005 (nZCv daif -PAN -UAO)
  |  pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
  |  lr : clk_register+0x438/0x720
  |  Call trace:
  |   scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi]
  |   devm_clk_hw_register+0x50/0xa0
  |   scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi]
  |   scpi_clocks_probe+0x528/0x70c [clk_scpi]
  |   platform_drv_probe+0x58/0xa8
  |   really_probe+0x260/0x3d0
  |   driver_probe_device+0x12c/0x148
  |   device_driver_attach+0x74/0x98
  |   __driver_attach+0xb4/0xe8
  |   bus_for_each_dev+0x88/0xe0
  |   driver_attach+0x30/0x40
  |   bus_add_driver+0x178/0x2b0
  |   driver_register+0x64/0x118
  |   __platform_driver_register+0x54/0x60
  |   scpi_clocks_driver_init+0x24/0x1000 [clk_scpi]
  |   do_one_initcall+0x54/0x220
  |   do_init_module+0x54/0x1c8
  |   load_module+0x14a4/0x1668
  |   __se_sys_finit_module+0xf8/0x110
  |   __arm64_sys_finit_module+0x24/0x30
  |   el0_svc_common+0x78/0x170
  |   el0_svc_handler+0x38/0x78
  |   el0_svc+0x8/0x340
  |  Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820)
  |  ---[ end trace 06feb22469d89fa8 ]---
  |  Kernel panic - not syncing: Fatal exception
  |  SMP: stopping secondary CPUs
  |  Kernel Offset: disabled
  |  CPU features: 0x10,a0002008
  |  Memory Limit: none
CVE-2024-47544 (Moderate severity, published 2024-12-11)
CVSS score: 6.2 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-476
Description: A flaw was found in the GStreamer library. Multiple NULL pointer dereferences in the MP4/MOV demuxer's CENC handling can cause crashes for certain input files, potentially allowing a malicious actor to trigger an application crash.
CVE-2024-42316 (Moderate severity, published 2024-08-16)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
CWE: CWE-369
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/mglru: fix div-by-zero in vmpressure_calc_level()

evict_folios() uses a second pass to reclaim folios that have gone through
page writeback and become clean before it finishes the first pass, since
folio_rotate_reclaimable() cannot handle those folios due to the
isolation.

The second pass tries to avoid potential double counting by deducting
scan_control->nr_scanned.  However, this can result in underflow of
nr_scanned, under a condition where shrink_folio_list() does not increment
nr_scanned, i.e., when folio_trylock() fails.

The underflow can cause the divisor, i.e., scale=scanned+reclaimed in
vmpressure_calc_level(), to become zero, resulting in the following crash:

  [exception RIP: vmpressure_work_fn+101]
  process_one_work at ffffffffa3313f2b

Since scan_control->nr_scanned has no established semantics, the potential
double counting has minimal risks.  Therefore, fix the problem by not
deducting scan_control->nr_scanned in evict_folios().
CVE-2024-56705 (Low severity, published 2024-12-27)
CVSS score: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Description: In the Linux kernel, the following vulnerability has been resolved:

media: atomisp: Add check for rgby_data memory allocation failure

In ia_css_3a_statistics_allocate(), there is no check on the allocation
result of the rgby_data memory. If rgby_data is not successfully
allocated, it may trigger the assert(host_stats->rgby_data) assertion in
ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.