huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
userfaultfd: don&#39;t BUG_ON() if khugepaged yanks our page table
CVE: CVE-2024-46838
Component: kernel
CWE: CWE-362
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-09-27T00:00:00+00:00

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

userfaultfd: don't BUG_ON() if khugepaged yanks our page table

Since khugepaged was changed to allow retracting page tables in file
mappings without holding the mmap lock, these BUG_ON()s are wrong - get
rid of them.

We could also remove the preceding "if (unlikely(...))" block, but then we
could reach pte_offset_map_lock() with transhuge pages not just for file
mappings but also for anonymous mappings - which would probably be fine
but I think is not necessarily expected.


Remediation:
fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats
CVE: CVE-2024-26686
Component: kernel
CWE: CWE-413
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-04-03T00:00:00+00:00

A vulnerability was found in the do_task_stat() function in the Linux kernel, where due to excessive lock contention, a potential hard lockup could be created. This can create a performance bottleneck and lead to kernel unresponsiveness.


Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
io_uring/tctx: work around xa_store() allocation error issue
CVE: CVE-2024-56584
Component: kernel
CWE: CWE-400
Severity: Low
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-12-27T00:00:00+00:00

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

io_uring/tctx: work around xa_store() allocation error issue

syzbot triggered the following WARN_ON:

WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51

which is the

WARN_ON_ONCE(!xa_empty(&tctx->xa));

sanity check in __io_uring_free() when a io_uring_task is going through
its final put. The syzbot test case includes injecting memory allocation
failures, and it very much looks like xa_store() can fail one of its
memory allocations and end up with ->head being non-NULL even though no
entries exist in the xarray.

Until this issue gets sorted out, work around it by attempting to
iterate entries in our xarray, and WARN_ON_ONCE() if one is found.


Remediation:
fou: remove warn in gue_gro_receive on unsupported protocol
CVE: CVE-2024-44940
Component: kernel
CWE: CWE-20
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-08-26T00:00:00+00:00

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

fou: remove warn in gue_gro_receive on unsupported protocol

Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is
not known or does not have a GRO handler.

Such a packet is easily constructed. Syzbot generates them and sets
off this warning.

Remove the warning as it is expected and not actionable.

The warning was previously reduced from WARN_ON to WARN_ON_ONCE in
commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad
proto callbacks").

Statement: This flaw does not seems to be impacting C and I of the kernel metadata, this could impact confidentiality (if it does) should be limited to IP protocol metadata only.

Remediation:
usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps
CVE: CVE-2024-40903
Component: kernel
CWE: CWE-416
Severity: Moderate
CVSS v3: 5.5/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H
Release date: 2024-07-12T00:00:00+00:00

A vulnerability was found in the tcpm_register_source_caps function in the Linux kernel's USB Type-C TCPM component. This issue arises when new, potentially invalid source capabilities are advertised while existing capabilities are unregistered, leading to a use-after-free condition if the registration fails.


Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
x86/efistub: Call mixed mode boot services on the firmware&#39;s stack
CVE: CVE-2024-35803
Component: kernel
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-05-17T00:00:00+00:00

A security vulnerability was identified in the Linux kernel's EFI (Extensible Firmware Interface) stub, specifically affecting systems operating in mixed-mode environments. The issue arises from the EFI stub's handling of boot services, which can lead to stack overflows and potential system instability.


Remediation:
net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()
CVE: CVE-2024-50000
Component: kernel
CWE: CWE-476
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-10-21T00:00:00+00:00

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

net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()

In mlx5e_tir_builder_alloc() kvzalloc() may return NULL
which is dereferenced on the next line in a reference
to the modify field.

Found by Linux Verification Center (linuxtesting.org) with SVACE.


Remediation:
double unlock in x86 guest IRQ handling
CVE: CVE-2024-31143
Component: xen
Release date: 2024-07-18T00:00:00+00:00

An optional feature of PCI MSI called "Multiple Message" allows a
device to use multiple consecutive interrupt vectors.  Unlike for MSI-X,
the setting up of these consecutive vectors needs to happen all in one
go.  In this handling an error path could be taken in different
situations, with or without a particular lock held.  This error path
wrongly releases the lock even when it is not currently held.


Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing
CVE: CVE-2024-58060
Component: kernel
CWE: CWE-416
Severity: Moderate
CVSS v3: 7.4/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Release date: 2024-01-01T00:00:00+00:00

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

bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing

There is a UAF report in the bpf_struct_ops when CONFIG_MODULES=n.
In particular, the report is on tcp_congestion_ops that has
a "struct module *owner" member.

For struct_ops that has a "struct module *owner" member,
it can be extended either by the regular kernel module or
by the bpf_struct_ops. bpf_try_module_get() will be used
to do the refcounting and different refcount is done
based on the owner pointer. When CONFIG_MODULES=n,
the btf_id of the "struct module" is missing:

WARN: resolve_btfids: unresolved symbol module

Thus, the bpf_try_module_get() cannot do the correct refcounting.

Not all subsystem's struct_ops requires the "struct module *owner" member.
e.g. the recent sched_ext_ops.

This patch is to disable bpf_struct_ops registration if
the struct_ops has the "struct module *" member and the
"struct module" btf_id is missing. The btf_type_is_fwd() helper
is moved to the btf.h header file for this test.

This has happened since the beginning of bpf_struct_ops which has gone
through many changes. The Fixes tag is set to a recent commit that this
patch can apply cleanly. Considering CONFIG_MODULES=n is not
common and the age of the issue, targeting for bpf-next also.

Statement: The default Red Hat Enterprise Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.

For the Red Hat Enterprise Linux 9 to confirm the current state, inspect the sysctl with the command:

    cat /proc/sys/kernel/unprivileged_bpf_disabled

The setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.

Remediation:
Potential SSRF in mod_rewrite
CVE: CVE-2024-39573
Component: httpd
CWE: CWE-20
Severity: Moderate
CVSS v3: 7.4/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Release date: 2024-07-01T00:00:00+00:00

A flaw was found in the mod_rewrite module of httpd. A potential SSRF allows an attacker to cause unsafe rules used in the RewriteRule directive to unexpectedly set up URLs to be handled by the mod_proxy module.

Statement: This issue only affects configurations with unsafe rules used in the RewriteRule directive.

Additionally, this flaw requires mod_rewrite and mod_proxy to be loaded and being used. These modules can be disabled via the configuration file if their functionality are not needed.

Red Hat Enterprise Linux 6 is not affected by this vulnerability because the vulnerable code was introduced in a newer version of httpd.

Remediation:
Before applying this update, make sure all previously released errata relevant to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258
Before applying the update, back up your existing installation, including all applications, configuration files, databases and database settings, and so on.

The References section of this erratum contains a download link. You must be logged in to download the update.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes
CVE: CVE-2024-41095
Component: kernel
CWE: CWE-476
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-07-29T00:00:00+00:00

A flaw was found in the Linux kernel’s nouveau module. The return value of the drm_mode_duplicate function is not checked in the nv17_tv_get_ld_modes function in the drivers/gpu/drm/nouveau/dispnv04/tvnv17.c file, possibly causing a NULL pointer dereference and resulting in a denial of service.


Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
PCI: Add missing bridge lock to pci_bus_lock()
CVE: CVE-2024-46750
Component: kernel
CWE: CWE-667
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-09-18T00:00:00+00:00

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

PCI: Add missing bridge lock to pci_bus_lock()

One of the true positives that the cfg_access_lock lockdep effort
identified is this sequence:

  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70
  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70
  Call Trace:
   <TASK>
   ? __warn+0x8c/0x190
   ? pci_bridge_secondary_bus_reset+0x5d/0x70
   ? report_bug+0x1f8/0x200
   ? handle_bug+0x3c/0x70
   ? exc_invalid_op+0x18/0x70
   ? asm_exc_invalid_op+0x1a/0x20
   ? pci_bridge_secondary_bus_reset+0x5d/0x70
   pci_reset_bus+0x1d8/0x270
   vmd_probe+0x778/0xa10
   pci_device_probe+0x95/0x120

Where pci_reset_bus() users are triggering unlocked secondary bus resets.
Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses
pci_bus_lock() before issuing the reset which locks everything *but* the
bridge itself.

For the same motivation as adding:

  bridge = pci_upstream_bridge(dev);
  if (bridge)
    pci_dev_lock(bridge);

to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add
pci_dev_lock() for @bus->self to pci_bus_lock().

[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:
https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]


Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
CVE: CVE-2024-26901
Component: kernel
CWE: CWE-402
Severity: Low
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-04-17T00:00:00+00:00

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

do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak

syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].

[1]
"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
 instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 _copy_to_user+0xbc/0x100 lib/usercopy.c:40
 copy_to_user include/linux/uaccess.h:191 [inline]
 do_sys_name_to_handle fs/fhandle.c:73 [inline]
 __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
 __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
 ...

Uninit was created at:
 slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
 slab_alloc_node mm/slub.c:3478 [inline]
 __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
 __do_kmalloc_node mm/slab_common.c:1006 [inline]
 __kmalloc+0x121/0x3c0 mm/slab_common.c:1020
 kmalloc include/linux/slab.h:604 [inline]
 do_sys_name_to_handle fs/fhandle.c:39 [inline]
 __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
 __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
 ...

Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240"

Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem.


Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
Before applying this update, make sure all previously released errata
relevant to your system have been applied.

For details on how to apply this update, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
dpll: fix dpll_pin_on_pin_register() for multiple parent pins
CVE: CVE-2024-36002
Component: kernel
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-05-20T00:00:00+00:00

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

dpll: fix dpll_pin_on_pin_register() for multiple parent pins

In scenario where pin is registered with multiple parent pins via
dpll_pin_on_pin_register(..), all belonging to the same dpll device.
A second call to dpll_pin_on_pin_unregister(..) would cause a call trace,
as it tries to use already released registration resources (due to fix
introduced in b446631f355e). In this scenario pin was registered twice,
so resources are not yet expected to be release until each registered
pin/pin pair is unregistered.

Currently, the following crash/call trace is produced when ice driver is
removed on the system with installed E810T NIC which includes dpll device:

WARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30
RIP: 0010:dpll_pin_ops+0x20/0x30
Call Trace:
 ? __warn+0x7f/0x130
 ? dpll_pin_ops+0x20/0x30
 dpll_msg_add_pin_freq+0x37/0x1d0
 dpll_cmd_pin_get_one+0x1c0/0x400
 ? __nlmsg_put+0x63/0x80
 dpll_pin_event_send+0x93/0x140
 dpll_pin_on_pin_unregister+0x3f/0x100
 ice_dpll_deinit_pins+0xa1/0x230 [ice]
 ice_remove+0xf1/0x210 [ice]

Fix by adding a parent pointer as a cookie when creating a registration,
also when searching for it. For the regular pins pass NULL, this allows to
create separated registration for each parent the pin is registered with.


Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
pinmux: Use sequential access to access desc->pinmux data
CVE: CVE-2024-47141
Component: kernel
CWE: CWE-667
Severity: Moderate
CVSS v3: 4.7/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-01-01T00:00:00+00:00

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

pinmux: Use sequential access to access desc->pinmux data

When two client of the same gpio call pinctrl_select_state() for the
same functionality, we are seeing NULL pointer issue while accessing
desc->mux_owner.

Let's say two processes A, B executing in pin_request() for the same pin
and process A updates the desc->mux_usecount but not yet updated the
desc->mux_owner while process B see the desc->mux_usecount which got
updated by A path and further executes strcmp and while accessing
desc->mux_owner it crashes with NULL pointer.

Serialize the access to mux related setting with a mutex lock.

	cpu0 (process A)			cpu1(process B)

pinctrl_select_state() {		  pinctrl_select_state() {
  pin_request() {				pin_request() {
  ...
						 ....
    } else {
         desc->mux_usecount++;
    						desc->mux_usecount && strcmp(desc->mux_owner, owner)) {

         if (desc->mux_usecount > 1)
               return 0;
         desc->mux_owner = owner;

  }						}


Remediation:
For details on how to apply this update, which includes the changes described in this advisory, refer to:

https://access.redhat.com/articles/11258

The system must be rebooted for this update to take effect.
remote attackers (from the client side) to trigger unnecessarily expensive server-side DHE modular-exponentiation calculations
CVE: CVE-2024-41996
Component: openssl
CWE: CWE-295
Severity: Low
CVSS v3: 5.8/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-08-26T06:15:04.603000+00:00

A vulnerability was found in the Diffie-Hellman Ephemeral (DHE) Key Agreement Protocol, where a malicious client can exploit the server's public key validation process. By forcing the server to use DHE and validating the order of public keys, the client can trigger expensive server-side modular exponentiation calculations. This issue results in asymmetric resource consumption, potentially leading to a denial of service (DoS) attack by overwhelming the server with computationally intensive operations.

Statement: This vulnerability is classified with a Low severity rather than Moderate because it requires specific conditions to be exploitable. The attack depends on the server being configured to use DHE key exchange and perform public key order validation, which is not the default in many configurations. Additionally, while the attack can cause increased CPU usage, leading to a potential denial of service, it does not directly compromise the confidentiality, integrity, or availability of the data being exchanged. The impact is limited to resource exhaustion, and mitigations such as rate limiting, alternative key exchange methods, or disabling DHE can effectively reduce the attack surface, making it less impacted than issues that could lead to direct data breaches or system compromise.

Remediation:
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
btrfs: fix deadlock with fiemap and extent locking
CVE: CVE-2024-35784
Component: kernel
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-05-17T00:00:00+00:00

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

btrfs: fix deadlock with fiemap and extent locking

While working on the patchset to remove extent locking I got a lockdep
splat with fiemap and pagefaulting with my new extent lock replacement
lock.

This deadlock exists with our normal code, we just don't have lockdep
annotations with the extent locking so we've never noticed it.

Since we're copying the fiemap extent to user space on every iteration
we have the chance of pagefaulting.  Because we hold the extent lock for
the entire range we could mkwrite into a range in the file that we have
mmap'ed.  This would deadlock with the following stack trace

[<0>] lock_extent+0x28d/0x2f0
[<0>] btrfs_page_mkwrite+0x273/0x8a0
[<0>] do_page_mkwrite+0x50/0xb0
[<0>] do_fault+0xc1/0x7b0
[<0>] __handle_mm_fault+0x2fa/0x460
[<0>] handle_mm_fault+0xa4/0x330
[<0>] do_user_addr_fault+0x1f4/0x800
[<0>] exc_page_fault+0x7c/0x1e0
[<0>] asm_exc_page_fault+0x26/0x30
[<0>] rep_movs_alternative+0x33/0x70
[<0>] _copy_to_user+0x49/0x70
[<0>] fiemap_fill_next_extent+0xc8/0x120
[<0>] emit_fiemap_extent+0x4d/0xa0
[<0>] extent_fiemap+0x7f8/0xad0
[<0>] btrfs_fiemap+0x49/0x80
[<0>] __x64_sys_ioctl+0x3e1/0xb50
[<0>] do_syscall_64+0x94/0x1a0
[<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76

I wrote an fstest to reproduce this deadlock without my replacement lock
and verified that the deadlock exists with our existing locking.

To fix this simply don't take the extent lock for the entire duration of
the fiemap.  This is safe in general because we keep track of where we
are when we're searching the tree, so if an ordered extent updates in
the middle of our fiemap call we'll still emit the correct extents
because we know what offset we were on before.

The only place we maintain the lock is searching delalloc.  Since the
delalloc stuff can change during writeback we want to lock the extent
range so we have a consistent view of delalloc at the time we're
checking to see if we need to set the delalloc flag.

With this patch applied we no longer deadlock with my testcase.


Remediation: