huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-58061: kernel: wifi: mac80211: prohibit deactivating all links
Component: kernel
Severity: Moderate
CWE: CWE-20 (Improper Input Validation)
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-03-06T00:00:00+00:00

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

wifi: mac80211: prohibit deactivating all links

In the internal API this calls this is a WARN_ON, but that
should remain since internally we want to know about bugs
that may cause this. Prevent deactivating all links in the
debugfs write directly.


Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.1.129, 6.12.13, 6.13.2, 6.14, 6.6.76
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: dfe9a043300261afe5eadc07b867a6810c4e999a
CVE-2024-58062: kernel: wifi: iwlwifi: mvm: avoid NULL pointer dereference
Component: kernel
Severity: Moderate
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-03-06T00:00:00+00:00

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

wifi: iwlwifi: mvm: avoid NULL pointer dereference

When iterating over the links of a vif, we need to make sure that the
pointer is valid (in other words - that the link exists) before
dereferncing it.
Use for_each_vif_active_link that also does the check.


Affected upstream versions: 6.12
Fixed upstream versions: 0, 6.12.13, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: fbb563ad5032a07ac83c746ce5c8de5f25b5ffd0
CVE-2024-58064: kernel: wifi: cfg80211: tests: Fix potential NULL dereference in test_cfg80211_parse_colocated_ap()
Component: kernel
Severity: Moderate
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-03-06T00:00:00+00:00

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

wifi: cfg80211: tests: Fix potential NULL dereference in test_cfg80211_parse_colocated_ap()

kunit_kzalloc() may return NULL, dereferencing it without NULL check may
lead to NULL dereference.
Add a NULL check for ies.


Affected upstream versions: 6.9
Fixed upstream versions: 0, 6.12.13, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 886271409603956edd09df229dde7442c410a872
CVE-2024-58068: kernel: OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized
Component: kernel
Severity: Low
CWE: CWE-395 (Use of NullPointerException Catch to Detect 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-03-06T00:00:00+00:00

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

OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized

If a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth
from the OPP table but the bandwidth table was not created because the
interconnect properties were missing in the OPP consumer node, the
kernel will crash with:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004
...
pc : _read_bw+0x8/0x10
lr : _opp_table_find_key+0x9c/0x174
...
Call trace:
  _read_bw+0x8/0x10 (P)
  _opp_table_find_key+0x9c/0x174 (L)
  _find_key+0x98/0x168
  dev_pm_opp_find_bw_ceil+0x50/0x88
...

In order to fix the crash, create an assert function to check
if the bandwidth table was created before trying to get a
bandwidth with _read_bw().


Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.129, 6.12.13, 6.13.2, 6.14, 6.6.76
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8532fd078d2a5286915d03bb0a0893ee1955acef
CVE-2024-58069: kernel: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-03-06T00:00:00+00:00

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

rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read

The nvmem interface supports variable buffer sizes, while the regmap
interface operates with fixed-size storage. If an nvmem client uses a
buffer size less than 4 bytes, regmap_read will write out of bounds
as it expects the buffer to point at an unsigned int.

Fix this by using an intermediary unsigned int to hold the value.

Statement: The issue is actual only for the latest versions of Red Hat Enterprise Linux (starting from the Red Hat Enterprise Linux 9). The bug could happen only if PCF85063 RTC chip being used. Only privileged user could trigger it (if have access to read some parameters from such device). The security impact is limited, because only few bytes of data corruption could happen (but still potentially could be used for privileges escalation).

Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.13, 6.13.2, 6.14, 6.6.76
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4
CVE-2024-58072: kernel: wifi: rtlwifi: remove unused check_buddy_priv
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.4 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-03-06T00:00:00+00:00

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

wifi: rtlwifi: remove unused check_buddy_priv

Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global
list of private data structures.

Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match
vendor version 2013.02.07") started adding the private data to that list at
probe time and added a hook, check_buddy_priv to find the private data from
a similar device.

However, that function was never used.

Besides, though there is a lock for that list, it is never used. And when
the probe fails, the private data is never removed from the list. This
would cause a second probe to access freed memory.

Remove the unused hook, structures and members, which will prevent the
potential race condition on the list and its corruption during a second
probe when probe fails.

Statement: The bug could happen during initialization (when probing PCI driver). The security impact is limited, because only privileged user can trigger the bug.

Affected upstream versions: 3.10
Fixed upstream versions: 0, 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.13, 6.13.2, 6.14, 6.6.76
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f801e754efa21bd61b3cc15ec7565696165b272f
CVE-2024-58075: kernel: crypto: tegra - do not transfer req when tegra init fails
Component: kernel
Severity: Moderate
CWE: CWE-252 (Unchecked Return Value)
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-03-06T00:00:00+00:00

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

crypto: tegra - do not transfer req when tegra init fails

The tegra_cmac_init or tegra_sha_init function may return an error when
memory is exhausted. It should not transfer the request when they return
an error.


Affected upstream versions: 6.10
Fixed upstream versions: 0, 6.12.13, 6.13.2, 6.14
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1dbc270f9df7f0ae1e591323431869059cee1b7d
CVE-2024-58077: kernel: ASoC: soc-pcm: don't use soc_pcm_ret() on .prepare callback
Component: kernel
Severity: Low
CWE: CWE-400 (Uncontrolled Resource Consumption)
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-03-06T00:00:00+00:00

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

ASoC: soc-pcm: don't use soc_pcm_ret() on .prepare callback

commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port"
log severity") ignores -EINVAL error message on common soc_pcm_ret().
It is used from many functions, ignoring -EINVAL is over-kill.

The reason why -EINVAL was ignored was it really should only be used
upon invalid parameters coming from userspace and in that case we don't
want to log an error since we do not want to give userspace a way to do
a denial-of-service attack on the syslog / diskspace.

So don't use soc_pcm_ret() on .prepare callback is better idea.


Affected upstream versions: 6.5
Fixed upstream versions: 0, 6.12.14, 6.13.3, 6.14, 6.6.78
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 79b8c7c93beb4f5882c9ee5b9ba73354fa4bc9ee
CVE-2024-58083: kernel: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()
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-03-06T00:00:00+00:00

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

KVM: Explicitly verify target vCPU is online in kvm_get_vcpu()

Explicitly verify the target vCPU is fully online _prior_ to clamping the
index in kvm_get_vcpu().  If the index is "bad", the nospec clamping will
generate '0', i.e. KVM will return vCPU0 instead of NULL.

In practice, the bug is unlikely to cause problems, as it will only come
into play if userspace or the guest is buggy or misbehaving, e.g. KVM may
send interrupts to vCPU0 instead of dropping them on the floor.

However, returning vCPU0 when it shouldn't exist per online_vcpus is
problematic now that KVM uses an xarray for the vCPUs array, as KVM needs
to insert into the xarray before publishing the vCPU to userspace (see
commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")),
i.e. before vCPU creation is guaranteed to succeed.

As a result, incorrectly providing access to vCPU0 will trigger a
use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu()
bails out of vCPU creation due to an error and frees vCPU0.  Commit
afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but
in doing so introduced an unsolvable teardown conundrum.  Preventing
accesses to vCPU0 before it's fully online will allow reverting commit
afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race.


Affected upstream versions: 4.14.120 < 4.15, 4.19.44 < 4.20, 5.0.17 < 5.1, 5.1
Fixed upstream versions: 0, 4.15, 4.20, 5.1, 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.14, 6.13.3, 6.14, 6.6.78
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5cce2ed69b00e022b5cdf0c49c82986abd2941a8
CVE-2024-58088: kernel: bpf: Fix deadlock when freeing cgroup storage
Component: kernel
Severity: Moderate
CWE: CWE-667 (Improper Locking)
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-03-12T00:00:00+00:00

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

bpf: Fix deadlock when freeing cgroup storage

The following commit
bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]")
first introduced deadlock prevention for fentry/fexit programs attaching
on bpf_task_storage helpers. That commit also employed the logic in map
free path in its v6 version.

Later bpf_cgrp_storage was first introduced in
c4bcfb38a95e ("bpf: Implement cgroup storage available to non-cgroup-attached bpf progs")
which faces the same issue as bpf_task_storage, instead of its busy
counter, NULL was passed to bpf_local_storage_map_free() which opened
a window to cause deadlock:

	<TASK>
		(acquiring local_storage->lock)
	_raw_spin_lock_irqsave+0x3d/0x50
	bpf_local_storage_update+0xd1/0x460
	bpf_cgrp_storage_get+0x109/0x130
	bpf_prog_a4d4a370ba857314_cgrp_ptr+0x139/0x170
	? __bpf_prog_enter_recur+0x16/0x80
	bpf_trampoline_6442485186+0x43/0xa4
	cgroup_storage_ptr+0x9/0x20
		(holding local_storage->lock)
	bpf_selem_unlink_storage_nolock.constprop.0+0x135/0x160
	bpf_selem_unlink_storage+0x6f/0x110
	bpf_local_storage_map_free+0xa2/0x110
	bpf_map_free_deferred+0x5b/0x90
	process_one_work+0x17c/0x390
	worker_thread+0x251/0x360
	kthread+0xd2/0x100
	ret_from_fork+0x34/0x50
	ret_from_fork_asm+0x1a/0x30
	</TASK>

Progs:
 - A: SEC("fentry/cgroup_storage_ptr")
   - cgid (BPF_MAP_TYPE_HASH)
	Record the id of the cgroup the current task belonging
	to in this hash map, using the address of the cgroup
	as the map key.
   - cgrpa (BPF_MAP_TYPE_CGRP_STORAGE)
	If current task is a kworker, lookup the above hash
	map using function parameter @owner as the key to get
	its corresponding cgroup id which is then used to get
	a trusted pointer to the cgroup through
	bpf_cgroup_from_id(). This trusted pointer can then
	be passed to bpf_cgrp_storage_get() to finally trigger
	the deadlock issue.
 - B: SEC("tp_btf/sys_enter")
   - cgrpb (BPF_MAP_TYPE_CGRP_STORAGE)
	The only purpose of this prog is to fill Prog A's
	hash map by calling bpf_cgrp_storage_get() for as
	many userspace tasks as possible.

Steps to reproduce:
 - Run A;
 - while (true) { Run B; Destroy B; }

Fix this issue by passing its busy counter to the free procedure so
it can be properly incremented before storage/smap locking.


Affected upstream versions: 6.2
Fixed upstream versions: 0, 6.12.17, 6.13.5, 6.14, 6.6.80
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6ecb9fa14eec5f15d97c84c36896871335f6ddfb
CVE-2024-58099: kernel: vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame
Component: kernel
Severity: Moderate
CWE: CWE-131 (Incorrect Calculation of Buffer Size)
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-04-29T00:00:00+00:00

A vulnerability was found in the Linux kernel's vmxnet3 network driver in the `vmxnet3_xdp_xmit_frame()` function. An incorrect DMA address calculation caused by the use of a fixed  (rather than dynamic) offset leads to a corrupt packet being sent out and subsequently dropped on the path. This can lead to system instability and a denial of service caused by persistent packet loss.


Affected upstream versions: 6.6
Fixed upstream versions: 0, 6.11.6, 6.12, 6.6.59
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 59ba6cdadb9c26b606a365eb9c9b25eb2052622d
CVE-2024-58239: kernel: tls: stop recv() if initial process_rx_list gave us non-DATA
Component: kernel
Severity: Moderate
CWE: CWE-241 (Improper Handling of Unexpected Data Type)
CVSS v3: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-08-22T00:00:00+00:00

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

tls: stop recv() if initial process_rx_list gave us non-DATA

If we have a non-DATA record on the rx_list and another record of the
same type still on the queue, we will end up merging them:
 - process_rx_list copies the non-DATA record
 - we start the loop and process the first available record since it's
   of the same type
 - we break out of the loop since the record was not DATA

Just check the record type and jump to the end in case process_rx_list
did some work.

Statement: The TLS recv path could mistakenly continue processing after process_rx_list() copied a non-DATA record, leading to merging of adjacent control records and inconsistent semantics. The fix makes recvmsg() stop immediately if the first processed record isn’t application data, preventing misinterpretation of TLS alerts/handshakes as data flow. Exploitation requires kTLS to be enabled and carefully crafted record sequencing, so the practical impact is limited to minor DoS of a TLS socket rather than confidentiality or integrity compromise.

Affected upstream versions: 5.1
Fixed upstream versions: 0, 5.10.211, 5.15.150, 5.4.270, 6.1.80, 6.6.19, 6.7.7, 6.8
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f310143961e2d9a0479fca117ce869f8aaecc140
CVE-2024-58240: kernel: tls: separate no-async decryption request handling from async
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L)
Public date: 2025-08-28T00:00:00+00:00

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

tls: separate no-async decryption request handling from async

If we're not doing async, the handling is much simpler. There's no
reference counting, we just need to wait for the completion to wake us
up and return its result.

We should preferably also use a separate crypto_wait. I'm not seeing a
UAF as I did in the past, I think aec7961916f3 ("tls: fix race between
async notify and socket close") took care of it.

This will make the next fix easier.

Statement: This patch refactors TLS RX decryption to use a separate, stack-local crypto_wait for the non-async path and bypass the async reference-counting/notification logic. It doesn’t fix a user-triggerable bug by itself; it’s a correctness/simplification change that reduces coupling and prepares the ground for a follow-up fix (“tls: fix use-after-free on failed backlog decryption”). No externally exploitable behavior changes are introduced.
The bug is actual for the older versions of Red Hat Enterprise Linux (before 9.3 and for all versions of the Red Hat Enterprise Linux 8) where patch aec7961916f3 "tls: fix race between async notify and socket close" not backported yet.
The CVSS being calculated for worse case scenario where the previous patch aec7961916f3 not applied yet (that leads to the use after free possibility).

Affected upstream versions: 4.13
Fixed upstream versions: 0, 6.1.149, 6.6.21, 6.7.9, 6.8
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 48905146d11dbf1ddbb2967319016a83976953f5
CVE-2024-6119: openssl: Possible denial of service in X.509 name checks
Component: openssl
Severity: Moderate
CWE: CWE-843 (Access of Resource Using Incompatible Type ('Type Confusion'))
CVSS v3: 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-09-04T00:00:00+00:00

A flaw was found in OpenSSL. Applications performing certificate name checks (e.g., TLS clients checking server certificates) may attempt to read an invalid memory address resulting in abnormal termination of the application process.

Statement: This vulnerability is classified as moderate severity rather than important because it primarily affects specific use cases involving certificate name checks against otherName subject alternative names, a scenario that is not commonly encountered. The issue only triggers a denial of service (DoS) by causing an abnormal application termination, without compromising the integrity, confidentiality, or availability of data at a broader scale. Additionally, TLS servers, which typically don't perform reference identity checks during client certificate validation, are largely unaffected. The impact is localized to certain TLS clients performing specific name comparisons, reducing the overall risk profile and justifying the moderate severity classification.

Affected upstream versions: 3.3.0 < 3.3.2, 3.2.0 < 3.2.3, 3.1.0 < 3.1.7, 3.0.0 < 3.0.15
Fixed upstream versions: 3.0.15, 3.1.7, 3.2.3, 3.3.2
Upstream repository: https://github.com/openssl/openssl
Upstream fix commit: 7dfcee2cd2a63b2c64b9b4b0850be64cb695b0a0
CVE-2024-6174: cloud-init: Cloud init permissions flaw
Component: cloud-init
Severity: Important
CWE: CWE-276 (Incorrect Default Permissions)
CVSS v3: 8.8 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-06-26T09:15:25.462000+00:00

An access permissions flaw was found in cloud-init. When a non-x86 platform is detected, cloud-init grants root access to a hardcoded URL with a local IP address, which creates a security exposure.

Statement: This vulnerability is Important rather than Moderate because it directly impacts the security boundary between a system’s local environment and potentially untrusted network metadata sources. On non-x86 platforms, the fallback to platform enumeration with default datasource scanning could allow cloud-init to treat a malicious or spoofed local metadata service as authoritative, granting root-level execution of arbitrary user-data or scripts during early boot. Since cloud-init runs before most security controls are active, exploitation would provide persistent and unrestricted system compromise with no user interaction.

Affected upstream versions: 0.7.9 < 25.1.3
Fixed upstream versions: 25.1.3
Upstream repository: https://github.com/canonical/cloud-init
Upstream fix commit: e3f42adc2674a38fb29e414cfbf96f884934b2d2
CVE-2024-6232: python: cpython: tarfile: ReDos via excessive backtracking while parsing header values
Component: python
Severity: Moderate
CWE: CWE-1333 (Inefficient Regular Expression Complexity)
CVSS v3: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-09-03T13:15:05.363000+00:00

A regular expression denial of service (ReDos) vulnerability was found in Python's tarfile module. Due to excessive backtracking while tarfile parses headers, an attacker may be able to trigger a denial of service via a specially crafted tar archive.

Statement: This vulnerability is classified as moderate severity rather than important because while it does allow for a denial of service (DoS) attack via excessive backtracking in the tarfile module, it does not enable remote code execution or compromise the integrity or confidentiality of data. Exploitation requires an attacker to provide a specially crafted tar archive and relies on the victim's system processing that file, which limits the attack vector.

Versions of python36:3.6/python36 as shipped with Red Hat Enterprise Linux 8 are marked as 'Not affected' as they just provide "symlinks" to the main python3 component, which provides the actual interpreter of the Python programming language.

Affected upstream versions: 3.9.0 < 3.9.20, 3.10.0 < 3.10.15, 3.11.0 < 3.11.10, 3.12.0 < 3.12.6, 3.13.0a1 < 3.13.0rc2
Fixed upstream versions: v3.12.6
Upstream repository: https://github.com/python/cpython
Upstream fix commit: 4eaf4891c12589e3c7bdad5f5b076e4c8392dd06
CVE-2024-6345: pypa/setuptools: Remote code execution via download functions in the package_index module in pypa/setuptools
Component: pypa/setuptools
Severity: Important
CWE: CWE-94 (Improper Control of Generation of Code ('Code Injection'))
CVSS v3: 8.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
Public date: 2024-07-15T00:00:00+00:00

A flaw was found in the package_index module of pypa/setuptools. Affected versions of this package allow remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system.

Statement: Red Hat OpenStack does not include setuptools. The ImcSdk component uses it only during compile time in our build systems, and we do not support recompiling SRPMs. As a result, Red Hat OpenStack is not affected by this flaw.

Python 2.7.18 was marked End of Life on 04/20/2020. No patches for Python 2 would be made available.

Affected upstream versions: unspecified < 70.0
Fixed upstream versions: 70.0
Upstream repository: https://github.com/pypa/setuptools
Upstream fix commit: 88807c7062788254f654ea8c03427adc859321f0