rainbutterfly/cve_corpus huggingface dataset:
CVE-2024-57931 selinux: ignore unknown extended permissions
In the Linux kernel, the following vulnerability has been resolved:

selinux: ignore unknown extended permissions

When evaluating extended permissions, ignore unknown permissions instead
of calling BUG(). This commit ensures that future permissions can be
added without interfering with older kernels.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:01:28.539Z
CVE-2024-57932 gve: guard XDP xmit NDO on existence of xdp queues
In the Linux kernel, the following vulnerability has been resolved:

gve: guard XDP xmit NDO on existence of xdp queues

In GVE, dedicated XDP queues only exist when an XDP program is installed
and the interface is up. As such, the NDO XDP XMIT callback should
return early if either of these conditions are false.

In the case of no loaded XDP program, priv->num_xdp_queues=0 which can
cause a divide-by-zero error, and in the case of interface down,
num_xdp_queues remains untouched to persist XDP queue count for the next
interface up, but the TX pointer itself would be NULL.

The XDP xmit callback also needs to synchronize with a device
transitioning from open to close. This synchronization will happen via
the GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,
which waits for any RCU critical sections at call-time to complete.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:01:29.212Z
CVE-2024-57933 gve: guard XSK operations on the existence of queues
In the Linux kernel, the following vulnerability has been resolved:

gve: guard XSK operations on the existence of queues

This patch predicates the enabling and disabling of XSK pools on the
existence of queues. As it stands, if the interface is down, disabling
or enabling XSK pools would result in a crash, as the RX queue pointer
would be NULL. XSK pool registration will occur as part of the next
interface up.

Similarly, xsk_wakeup needs be guarded against queues disappearing
while the function is executing, so a check against the
GVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with the
disabling of the bit and the synchronize_net() in gve_turndown.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:01:29.882Z
CVE-2024-57934 fgraph: Add READ_ONCE() when accessing fgraph_array[]
In the Linux kernel, the following vulnerability has been resolved:

fgraph: Add READ_ONCE() when accessing fgraph_array[]

In __ftrace_return_to_handler(), a loop iterates over the fgraph_array[]
elements, which are fgraph_ops. The loop checks if an element is a
fgraph_stub to prevent using a fgraph_stub afterward.

However, if the compiler reloads fgraph_array[] after this check, it might
race with an update to fgraph_array[] that introduces a fgraph_stub. This
could result in the stub being processed, but the stub contains a null
"func_hash" field, leading to a NULL pointer dereference.

To ensure that the gops compared against the fgraph_stub matches the gops
processed later, add a READ_ONCE(). A similar patch appears in commit
63a8dfb ("function_graph: Add READ_ONCE() when accessing fgraph_array[]").
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:01:30.537Z
CVE-2024-57935 RDMA/hns: Fix accessing invalid dip_ctx during destroying QP
In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix accessing invalid dip_ctx during destroying QP

If it fails to modify QP to RTR, dip_ctx will not be attached. And
during detroying QP, the invalid dip_ctx pointer will be accessed.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: unaffected
Published: 2025-01-21T12:01:31.236Z
CVE-2024-57936 RDMA/bnxt_re: Fix max SGEs for the Work Request
In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Fix max SGEs for the Work Request

Gen P7 supports up to 13 SGEs for now. WQE software structure
can hold only 6 now. Since the max send sge is reported as
13, the stack can give requests up to 13 SGEs. This is causing
traffic failures and system crashes.

Use the define for max SGE supported for variable size. This
will work for both static and variable WQEs.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:01:31.907Z
CVE-2024-57938 net/sctp: Prevent autoclose integer overflow in sctp_association_init()
In the Linux kernel, the following vulnerability has been resolved:

net/sctp: Prevent autoclose integer overflow in sctp_association_init()

While by default max_autoclose equals to INT_MAX / HZ, one may set
net.sctp.max_autoclose to UINT_MAX. There is code in
sctp_association_init() that can consequently trigger overflow.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:09:15.412Z
CVE-2024-57939 riscv: Fix sleeping in invalid context in die()
In the Linux kernel, the following vulnerability has been resolved:

riscv: Fix sleeping in invalid context in die()

die() can be called in exception handler, and therefore cannot sleep.
However, die() takes spinlock_t which can sleep with PREEMPT_RT enabled.
That causes the following warning:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex
preempt_count: 110001, expected: 0
RCU nest depth: 0, expected: 0
CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
    dump_backtrace+0x1c/0x24
    show_stack+0x2c/0x38
    dump_stack_lvl+0x5a/0x72
    dump_stack+0x14/0x1c
    __might_resched+0x130/0x13a
    rt_spin_lock+0x2a/0x5c
    die+0x24/0x112
    do_trap_insn_illegal+0xa0/0xea
    _new_vmalloc_restore_context_a0+0xcc/0xd8
Oops - illegal instruction [#1]

Switch to use raw_spinlock_t, which does not sleep even with PREEMPT_RT
enabled.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:18:08.433Z
CVE-2024-57940 exfat: fix the infinite loop in exfat_readdir()
In the Linux kernel, the following vulnerability has been resolved:

exfat: fix the infinite loop in exfat_readdir()

If the file system is corrupted so that a cluster is linked to
itself in the cluster chain, and there is an unused directory
entry in the cluster, 'dentry' will not be incremented, causing
condition 'dentry < max_dentries' unable to prevent an infinite
loop.

This infinite loop causes s_lock not to be released, and other
tasks will hang, such as exfat_sync_fs().

This commit stops traversing the cluster chain when there is unused
directory entry in the cluster to avoid this infinite loop.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:18:09.150Z
CVE-2024-57941 netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled
In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled

When the caching for a cookie is temporarily disabled (e.g. due to a DIO
write on that file), future copying to the cache for that file is disabled
until all fds open on that file are closed.  However, if netfslib is using
the deprecated PG_private_2 method (such as is currently used by ceph), and
decides it wants to copy to the cache, netfs_advance_write() will just bail
at the first check seeing that the cache stream is unavailable, and
indicate that it dealt with all the content.

This means that we have no subrequests to provide notifications to drive
the state machine or even to pin the request and the request just gets
discarded, leaving the folios with PG_private_2 set.

Fix this by jumping directly to cancel the request if the cache is not
available.  That way, we don't remove mark3 from the folio_queue list and
netfs_pgpriv2_cancel() will clean up the folios.

This was found by running the generic/013 xfstest against ceph with an
active cache and the "-o fsc" option passed to ceph.  That would usually
hang
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:18:09.834Z
CVE-2024-57942 netfs: Fix ceph copy to cache on write-begin
In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix ceph copy to cache on write-begin

At the end of netfs_unlock_read_folio() in which folios are marked
appropriately for copying to the cache (either with by being marked dirty
and having their private data set or by having PG_private_2 set) and then
unlocked, the folio_queue struct has the entry pointing to the folio
cleared.  This presents a problem for netfs_pgpriv2_write_to_the_cache(),
which is used to write folios marked with PG_private_2 to the cache as it
expects to be able to trawl the folio_queue list thereafter to find the
relevant folios, leading to a hang.

Fix this by not clearing the folio_queue entry if we're going to do the
deprecated copy-to-cache.  The clearance will be done instead as the folios
are written to the cache.

This can be reproduced by starting cachefiles, mounting a ceph filesystem
with "-o fsc" and writing to it.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:18:10.532Z
CVE-2024-57943 exfat: fix the new buffer was not zeroed before writing
In the Linux kernel, the following vulnerability has been resolved:

exfat: fix the new buffer was not zeroed before writing

Before writing, if a buffer_head marked as new, its data must
be zeroed, otherwise uninitialized data in the page cache will
be written.

So this commit uses folio_zero_new_buffers() to zero the new
buffers before ->write_end().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:18:11.195Z
CVE-2024-57944 iio: adc: ti-ads1298: Add NULL check in ads1298_init
In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ti-ads1298: Add NULL check in ads1298_init

devm_kasprintf() can return a NULL pointer on failure. A check on the
return value of such a call in ads1298_init() is missing. Add it.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:18:11.882Z
CVE-2024-57945 riscv: mm: Fix the out of bound issue of vmemmap address
In the Linux kernel, the following vulnerability has been resolved:

riscv: mm: Fix the out of bound issue of vmemmap address

In sparse vmemmap model, the virtual address of vmemmap is calculated as:
((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)).
And the struct page's va can be calculated with an offset:
(vmemmap + (pfn)).

However, when initializing struct pages, kernel actually starts from the
first page from the same section that phys_ram_base belongs to. If the
first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then
we get an va below VMEMMAP_START when calculating va for it's struct page.

For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the
first page in the same section is actually pfn 0x80000. During
init_unavailable_range(), we will initialize struct page for pfn 0x80000
with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is
below VMEMMAP_START as well as PCI_IO_END.

This commit fixes this bug by introducing a new variable
'vmemmap_start_pfn' which is aligned with memory section size and using
it to calculate vmemmap address instead of phys_ram_base.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:18:12.548Z
CVE-2024-57946 virtio-blk: don't keep queue frozen during system suspend
In the Linux kernel, the following vulnerability has been resolved:

virtio-blk: don't keep queue frozen during system suspend

Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before
deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's
PM callbacks. And the motivation is to drain inflight IOs before suspending.

block layer's queue freeze looks very handy, but it is also easy to cause
deadlock, such as, any attempt to call into bio_queue_enter() may run into
deadlock if the queue is frozen in current context. There are all kinds
of ->suspend() called in suspend context, so keeping queue frozen in the
whole suspend context isn't one good idea. And Marek reported lockdep
warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().

[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/

Given the motivation is to drain in-flight IOs, it can be done by calling
freeze & unfreeze, meantime restore to previous behavior by keeping queue
quiesced during suspend.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-21T12:22:53.324Z
CVE-2024-57947 netfilter: nf_set_pipapo: fix initial map fill
In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_set_pipapo: fix initial map fill

The initial buffer has to be inited to all-ones, but it must restrict
it to the size of the first field, not the total field size.

After each round in the map search step, the result and the fill map
are swapped, so if we have a set where f->bsize of the first element
is smaller than m->bsize_max, those one-bits are leaked into future
rounds result map.

This makes pipapo find an incorrect matching results for sets where
first field size is not the largest.

Followup patch adds a test case to nft_concat_range.sh selftest script.

Thanks to Stefano Brivio for pointing out that we need to zero out
the remainder explicitly, only correcting memset() argument isn't enough.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-01-23T13:54:20.267Z
CVE-2024-57949 irqchip/gic-v3-its: Don't enable interrupts in its_irq_set_vcpu_affinity()
In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v3-its: Don't enable interrupts in its_irq_set_vcpu_affinity()

The following call-chain leads to enabling interrupts in a nested interrupt
disabled section:

irq_set_vcpu_affinity()
  irq_get_desc_lock()
     raw_spin_lock_irqsave()   <--- Disable interrupts
  its_irq_set_vcpu_affinity()
     guard(raw_spinlock_irq)   <--- Enables interrupts when leaving the guard()
  irq_put_desc_unlock()        <--- Warns because interrupts are enabled

This was broken in commit b97e8a2f7130, which replaced the original
raw_spin_[un]lock() pair with guard(raw_spinlock_irq).

Fix the issue by using guard(raw_spinlock).

[ tglx: Massaged change log ]
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-02-09T11:37:23.906Z
CVE-2024-57950 drm/amd/display: Initialize denominator defaults to 1
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Initialize denominator defaults to 1

[WHAT & HOW]
Variables, used as denominators and maybe not assigned to other values,
should be initialized to non-zero to avoid DIVIDE_BY_ZERO, as reported
by Coverity.

(cherry picked from commit e2c4c6c10542ccfe4a0830bb6c9fd5b177b7bbb7)
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-02-10T15:58:42.107Z
CVE-2024-57951 hrtimers: Handle CPU state correctly on hotplug
In the Linux kernel, the following vulnerability has been resolved:

hrtimers: Handle CPU state correctly on hotplug

Consider a scenario where a CPU transitions from CPUHP_ONLINE to halfway
through a CPU hotunplug down to CPUHP_HRTIMERS_PREPARE, and then back to
CPUHP_ONLINE:

Since hrtimers_prepare_cpu() does not run, cpu_base.hres_active remains set
to 1 throughout. However, during a CPU unplug operation, the tick and the
clockevents are shut down at CPUHP_AP_TICK_DYING. On return to the online
state, for instance CFS incorrectly assumes that the hrtick is already
active, and the chance of the clockevent device to transition to oneshot
mode is also lost forever for the CPU, unless it goes back to a lower state
than CPUHP_HRTIMERS_PREPARE once.

This round-trip reveals another issue; cpu_base.online is not set to 1
after the transition, which appears as a WARN_ON_ONCE in enqueue_hrtimer().

Aside of that, the bulk of the per CPU state is not reset either, which
means there are dangling pointers in the worst case.

Address this by adding a corresponding startup() callback, which resets the
stale per CPU state and sets the online flag.

[ tglx: Make the new callback unconditionally available, remove the online
  	modification in the prepare() callback and clear the remaining
  	state in the starting callback instead of the prepare callback ]
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-02-12T13:27:53.124Z
CVE-2024-57952 Revert "libfs: fix infinite directory reads for offset dir"
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.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-02-12T13:52:45.229Z
CVE-2024-57953 rtc: tps6594: Fix integer overflow on 32bit systems
In the Linux kernel, the following vulnerability has been resolved:

rtc: tps6594: Fix integer overflow on 32bit systems

The problem is this multiply in tps6594_rtc_set_offset()

	tmp = offset * TICKS_PER_HOUR;

The "tmp" variable is an s64 but "offset" is a long in the
(-277774)-277774 range.  On 32bit systems a long can hold numbers up to
approximately two billion.  The number of TICKS_PER_HOUR is really large,
(32768 * 3600) or roughly a hundred million.  When you start multiplying
by a hundred million it doesn't take long to overflow the two billion
mark.

Probably the safest way to fix this is to change the type of
TICKS_PER_HOUR to long long because it's such a large number.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-02-27T02:07:01.598Z
CVE-2024-57954 
Permission verification vulnerability in the media library module
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
Problem types: cwe_id: CWE-285
description: CWE-285 Improper Authorization
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: NONE
baseScore: 6.2
baseSeverity: MEDIUM
confidentialityImpact: HIGH
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
version: 3.1
Published: 2025-02-06T12:23:41.778Z
CVE-2024-57955 
Arbitrary write vulnerability in the Gallery module 
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
Problem types: cwe_id: CWE-787
description: CWE-787 Out-of-bounds Write
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: NONE
baseScore: 6.1
baseSeverity: MEDIUM
confidentialityImpact: HIGH
integrityImpact: LOW
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N
version: 3.1
Published: 2025-02-06T12:25:22.348Z
CVE-2024-57956 
Out-of-bounds read vulnerability in the interpreter string module
Impact: Successful exploitation of this vulnerability may affect availability.
Problem types: cwe_id: CWE-680
description: CWE-680 Integer Overflow to Buffer Overflow
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: LOW
baseScore: 2.8
baseSeverity: LOW
confidentialityImpact: NONE
integrityImpact: NONE
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L
version: 3.1
Published: 2025-02-06T12:26:10.611Z
CVE-2024-57957 
Vulnerability of improper log information control in the UI framework module
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
Problem types: cwe_id: CWE-657
description: CWE-657 Violation of Secure Design Principles
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: PHYSICAL
availabilityImpact: HIGH
baseScore: 6.6
baseSeverity: MEDIUM
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
version: 3.1
Published: 2025-02-06T12:27:07.878Z
CVE-2024-57958 
Out-of-bounds array read vulnerability in the FFRT module
Impact: Successful exploitation of this vulnerability may cause features to perform abnormally.
Problem types: cwe_id: CWE-125
description: CWE-125 Out-of-bounds Read
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: LOW
baseScore: 5.7
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: NONE
privilegesRequired: NONE
scope: CHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:L
version: 3.1
Published: 2025-02-06T12:29:41.313Z