huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
tcp: prevent concurrent execution of tcp_sk_exit_batch
CVE: CVE-2024-44991
Component: kernel
CWE: CWE-362
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-09-04T00:00:00+00:00

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

tcp: prevent concurrent execution of tcp_sk_exit_batch

Its possible that two threads call tcp_sk_exit_batch() concurrently,
once from the cleanup_net workqueue, once from a task that failed to clone
a new netns.  In the latter case, error unwinding calls the exit handlers
in reverse order for the 'failed' netns.

tcp_sk_exit_batch() calls tcp_twsk_purge().
Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"),
this function picks up twsk in any dying netns, not just the one passed
in via exit_batch list.

This means that the error unwind of setup_net() can "steal" and destroy
timewait sockets belonging to the exiting netns.

This allows the netns exit worker to proceed to call

WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount));

without the expected 1 -> 0 transition, which then splats.

At same time, error unwind path that is also running inet_twsk_purge()
will splat as well:

WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210
...
 refcount_dec include/linux/refcount.h:351 [inline]
 inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70
 inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221
 inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304
 tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522
 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
 setup_net+0x714/0xb40 net/core/net_namespace.c:375
 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508
 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110

... because refcount_dec() of tw_refcount unexpectedly dropped to 0.

This doesn't seem like an actual bug (no tw sockets got lost and I don't
see a use-after-free) but as erroneous trigger of debug check.

Add a mutex to force strict ordering: the task that calls tcp_twsk_purge()
blocks other task from doing final _dec_and_test before mutex-owner has
removed all tw sockets of dying netns.


Remediation:
drm/xe: Add outer runtime_pm protection to xe_live_ktest@xe_dma_buf
CVE: CVE-2024-42146
Component: kernel
Severity: Low
CVSS v3: 3.4/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Release date: 2024-07-30T00:00:00+00:00

Any kunit doing any memory access should get their own runtime_pm outer references since they don't use the standard driver API entries.

Statement: No Red Hat products are affected by this vulnerability.

Remediation:
CVE: CVE-2024-11524
Component: IrfanView DXF File Parsing Memory Corruption Remote Code Execution Vulnerability
Release date: 2024-11-21T20:51:34.598000+00:00

IrfanView DXF File Parsing Memory Corruption Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of IrfanView. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the parsing of DXF files. The issue results from the lack of proper validation of user-supplied data, which can result in a memory corruption condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-24598.

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:
Denial of service risk in file picker unzip functionality
CVE: CVE-2024-25978
Component: MSA-24-0001
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-02-19T00:00:00+00:00

Insufficient file size checks resulted in a denial of service risk in the file picker's unzip functionality.

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:
From CVEorg collector
CVE: CVE-2024-21192
Component: Oracle Fusion Middleware
Release date: 2024-10-15T19:52:35.130000+00:00

Vulnerability in the Oracle Enterprise Manager for Fusion Middleware product of Oracle Fusion Middleware (component: WebLogic Mgmt).   The supported version that is affected is 12.2.1.4.0. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle Enterprise Manager for Fusion Middleware executes to compromise Oracle Enterprise Manager for Fusion Middleware.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Enterprise Manager for Fusion Middleware accessible data. CVSS 3.1 Base Score 4.4 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N).

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:
incomplete fix for CVE-2023-38709
CVE: CVE-2024-42516
Component: httpd
CWE: CWE-113
Severity: Moderate
CVSS v3: 6.7/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N
Release date: 2024-01-01T00:00:00+00:00

A flaw was found in httpd. The response headers are not sanitized before an HTTP response is sent when a malicious backend can insert a Content-Type, Content-Encoding, or some other headers. These issues lead to HTTP response splitting. This CVE provides a "complete" fix for CVE-2023-38709.

Statement: This flaw is only exploitable by a malicious backend or a malicious application, but may also affect forward proxy configurations.

This issue is classified as a Moderate vulnerability because successful exploitation requires a highly specific and constrained setup. Namely, the attacker must already have the ability to influence backend responses—such as injecting malicious headers like Content-Type or Content-Encoding—which typically implies a compromised or poorly controlled upstream service. In properly configured systems, frontend servers like Apache sanitize or strictly validate backend output, limiting exposure. Furthermore, HTTP response splitting does not inherently lead to remote code execution or privilege escalation on the server itself; instead, its effects are typically confined to manipulating client-side behavior such as caching or redirection.

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.
drm/amdgpu: Fix the warning division or modulo by zero
CVE: CVE-2024-46806
Component: kernel
CWE: CWE-369
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:

drm/amdgpu: Fix the warning division or modulo by zero

Checks the partition mode and returns an error for an invalid mode.


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.
wifi: mt76: mt7996: use hweight16 to get correct tx antenna
CVE: CVE-2024-47714
Component: kernel
CWE: CWE-787
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:

wifi: mt76: mt7996: use hweight16 to get correct tx antenna

The chainmask is u16 so using hweight8 cannot get correct tx_ant.
Without this patch, the tx_ant of band 2 would be -1 and lead to the
following issue:
BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]


Remediation:
multiple CVEs
CVE: CVE-2024-32614
Component: hdf5
Severity: Moderate
Release date: 2024-05-10T00:00:00+00:00

HDF5 Library through 1.14.3 has a SEGV in H5VM_memcpyvv in H5VM.c.


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
powerpc/kasan: Fix addr error caused by page alignment
CVE: CVE-2024-26712
Component: kernel
CWE: CWE-20
Severity: Low
CVSS v3: 5.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-04-03T00:00:00+00:00

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

powerpc/kasan: Fix addr error caused by page alignment

In kasan_init_region, when k_start is not page aligned, at the begin of
for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then
`va = block + k_cur - k_start` is less than block, the addr va is invalid,
because the memory address space from va to block is not alloced by
memblock_alloc, which will not be reserved by memblock_reserve later, it
will be used by other places.

As a result, memory overwriting occurs.

for example:
int __init __weak kasan_init_region(void *start, size_t size)
{
[...]
	/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */
	block = memblock_alloc(k_end - k_start, PAGE_SIZE);
	[...]
	for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {
		/* at the begin of for loop
		 * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)
		 * va(dcd96c00) is less than block(dcd97000), va is invalid
		 */
		void *va = block + k_cur - k_start;
		[...]
	}
[...]
}

Therefore, page alignment is performed on k_start before
memblock_alloc() to ensure the validity of the VA address.


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.
stack-based buffer overflow vulnerabilities exist in the readOF
CVE: CVE-2024-24685
Component: meshlab
CVSS v3: 7.7/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Release date: 2024-05-28T00:00:00+00:00

Multiple stack-based buffer overflow vulnerabilities exist in the readOFF functionality of libigl v2.5.0. A specially crafted .off file can lead to stack-based buffer overflow. An attacker can provide a malicious file to trigger this vulnerability.This vulnerability concerns the parsing of comments within the vertex section of an `.off`  file processed via the `readOFF` function.

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:
keycloak-services: Keycloak Denial of Service
CVE: CVE-2024-10270
Component: org.keycloak
CWE: CWE-1333
Severity: Moderate
CVSS v3: 6.7/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-11-21T16:54:00+00:00

A vulnerability was found in the Keycloak-services package. If untrusted data is passed to the SearchQueryUtils method, it could lead to a denial of service (DoS) scenario by exhausting system resources due to a Regex complexity.

Statement: Red Hat Enterprise Application Platform 8 does not ship or provide the affected component, and so is not affected by this flaw.

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 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.
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
Private Network Permission Enabled by default in corydolphin/flask-cors
CVE: CVE-2024-6221
Component: flask-cors
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Release date: 2024-08-18T00:00:00+00:00

A flaw was found in flask-cors. The private network cors header, Access-Control-Allow-Private-Network, is always sent with the true value without any option to configure. This behavior can expose private network resources to unauthorized external access, leading to significant security risks.

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:
Stack-based buffer overflow vulnerability in ORC
CVE: CVE-2024-40897
Component: orc
Severity: Moderate
CVSS v3: 6.7/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H
Release date: 2024-07-26T00:00:00+00:00

Stack-based buffer overflow vulnerability exists in orcparse.c of ORC. If a developer is tricked to process a specially crafted file with the affected ORC compiler, an arbitrary code may be executed on the developer's build environment. This may lead to compromise of developer machines or CI build environments.


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.
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
CVE: CVE-2024-35997
Component: kernel
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-05-20T00:00:00+00:00

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

HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up

The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
However, this is not necessary, because I2C core already has its own
locking for that.

More importantly, this flag can cause a lock-up: if the flag is set in
i2c_hid_xfer() and an interrupt happens, the interrupt handler
(i2c_hid_irq) will check this flag and return immediately without doing
anything, then the interrupt handler will be invoked again in an
infinite loop.

Since interrupt handler is an RT task, it takes over the CPU and the
flag-clearing task never gets scheduled, thus we have a lock-up.

Delete this unnecessary flag.


Remediation:
virtuoso-opensource: Denial of Service via crafted SQL statements
CVE: CVE-2024-57651
Component: virtuoso-opensource
CWE: CWE-20
Severity: Moderate
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-01-01T00:00:00+00:00

An issue in the jp_add component of openlink virtuoso-opensource v7.2.11 allows attackers to cause a Denial of Service (DoS) via crafted SQL statements.


Remediation:
usb: xhci: Fix NULL pointer dereference on certain command aborts
CVE: CVE-2024-57981
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-01-01T00:00:00+00:00

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

usb: xhci: Fix NULL pointer dereference on certain command aborts

If a command is queued to the final usable TRB of a ring segment, the
enqueue pointer is advanced to the subsequent link TRB and no further.
If the command is later aborted, when the abort completion is handled
the dequeue pointer is advanced to the first TRB of the next segment.

If no further commands are queued, xhci_handle_stopped_cmd_ring() sees
the ring pointers unequal and assumes that there is a pending command,
so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.

Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell
ring likely is unnecessary too, but it's harmless. Leave it alone.

This is probably Bug 219532, but no confirmation has been received.

The issue has been independently reproduced and confirmed fixed using
a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.
Everything continued working normally after several prevented crashes.


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.
brd: defer automatic disk creation until module initialization succeeds
CVE: CVE-2024-56693
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-12-28T00:00:00+00:00

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

brd: defer automatic disk creation until module initialization succeeds

My colleague Wupeng found the following problems during fault injection:

BUG: unable to handle page fault for address: fffffbfff809d073
PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0
Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.1-2.fc37 04/01/2014
RIP: 0010:__asan_load8+0x4c/0xa0
...
Call Trace:
 <TASK>
 blkdev_put_whole+0x41/0x70
 bdev_release+0x1a3/0x250
 blkdev_release+0x11/0x20
 __fput+0x1d7/0x4a0
 task_work_run+0xfc/0x180
 syscall_exit_to_user_mode+0x1de/0x1f0
 do_syscall_64+0x6b/0x170
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

loop_init() is calling loop_add() after __register_blkdev() succeeds and
is ignoring disk_add() failure from loop_add(), for loop_add() failure
is not fatal and successfully created disks are already visible to
bdev_open().

brd_init() is currently calling brd_alloc() before __register_blkdev()
succeeds and is releasing successfully created disks when brd_init()
returns an error. This can cause UAF for the latter two case:

case 1:
    T1:
modprobe brd
  brd_init
    brd_alloc(0) // success
      add_disk
        disk_scan_partitions
          bdev_file_open_by_dev // alloc file
          fput // won't free until back to userspace
    brd_alloc(1) // failed since mem alloc error inject
  // error path for modprobe will release code segment
  // back to userspace
  __fput
    blkdev_release
      bdev_release
        blkdev_put_whole
          bdev->bd_disk->fops->release // fops is freed now, UAF!

case 2:
    T1:                            T2:
modprobe brd
  brd_init
    brd_alloc(0) // success
                                   open(/dev/ram0)
    brd_alloc(1) // fail
  // error path for modprobe

                                   close(/dev/ram0)
                                   ...
                                   /* UAF! */
                                   bdev->bd_disk->fops->release

Fix this problem by following what loop_init() does. Besides,
reintroduce brd_devices_mutex to help serialize modifications to
brd_list.


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.
mISDN: Fix a use after free in hfcmulti_tx()
CVE: CVE-2024-42280
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-08-17T00:00:00+00:00

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

mISDN: Fix a use after free in hfcmulti_tx()

Don't dereference *sp after calling dev_kfree_skb(*sp).


Remediation:
bpf: Fix re-attachment branch in bpf_tracing_prog_attach
CVE: CVE-2024-26591
Component: kernel
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-02-22T00:00:00+00:00

bpf: Fix re-attachment branch in bpf_tracing_prog_attach

The following case can cause a crash due to missing attach_btf:

1) load rawtp program
2) load fentry program with rawtp as target_fd
3) create tracing link for fentry program with target_fd = 0
4) repeat 3

In the end we have:

- prog->aux->dst_trampoline == NULL
- tgt_prog == NULL (because we did not provide target_fd to link_create)
- prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)
- the program was loaded for tgt_prog but we have no way to find out which one

    BUG: kernel NULL pointer dereference, address: 0000000000000058
    Call Trace:
     
     ? __die+0x20/0x70
     ? page_fault_oops+0x15b/0x430
     ? fixup_exception+0x22/0x330
     ? exc_page_fault+0x6f/0x170
     ? asm_exc_page_fault+0x22/0x30
     ? bpf_tracing_prog_attach+0x279/0x560
     ? btf_obj_id+0x5/0x10
     bpf_tracing_prog_attach+0x439/0x560
     __sys_bpf+0x1cf4/0x2de0
     __x64_sys_bpf+0x1c/0x30
     do_syscall_64+0x41/0xf0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76

Return -EINVAL in this situation.


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.
No mitigation is currently available for this vulnerability. Make sure to perform the updates as they become available.
riscv/purgatory: align riscv_kernel_entry
CVE: CVE-2024-43868
Component: kernel
CWE: CWE-20
Severity: Low
CVSS v3: 5.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2024-08-20T00:00:00+00:00

When alignment handling is delegated to the kernel, everything must be word-aligned in purgatory, since the trap handler is then set to the kexec one. Without the alignment, hitting the exception would ultimately crash. On other occasions, the kernel's handler would take care of exceptions. This has been tested on a JH7110 SoC with oreboot and its SBI delegating unaligned access exceptions and the kernel configured to handle them.


Remediation:
From CVEorg collector
CVE: CVE-2024-21254
Component: Oracle Analytics
Release date: 2024-10-15T19:52:52.628000+00:00

Vulnerability in the Oracle BI Publisher product of Oracle Analytics (component: Web Server).  Supported versions that are affected are 7.0.0.0.0, 7.6.0.0.0 and  12.2.1.4.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle BI Publisher.  Successful attacks of this vulnerability can result in takeover of Oracle BI Publisher. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

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:
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
CVE: CVE-2024-36968
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-06-08T00:00:00+00:00

in linux kernel bluetooth L2CAP, l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range.


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.