rainbutterfly/cve_corpus huggingface dataset:
CVE-2024-58090 sched/core: Prevent rescheduling when interrupts are disabled
In the Linux kernel, the following vulnerability has been resolved:

sched/core: Prevent rescheduling when interrupts are disabled

David reported a warning observed while loop testing kexec jump:

  Interrupts enabled after irqrouter_resume+0x0/0x50
  WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220
   kernel_kexec+0xf6/0x180
   __do_sys_reboot+0x206/0x250
   do_syscall_64+0x95/0x180

The corresponding interrupt flag trace:

  hardirqs last  enabled at (15573): [<ffffffffa8281b8e>] __up_console_sem+0x7e/0x90
  hardirqs last disabled at (15580): [<ffffffffa8281b73>] __up_console_sem+0x63/0x90

That means __up_console_sem() was invoked with interrupts enabled. Further
instrumentation revealed that in the interrupt disabled section of kexec
jump one of the syscore_suspend() callbacks woke up a task, which set the
NEED_RESCHED flag. A later callback in the resume path invoked
cond_resched() which in turn led to the invocation of the scheduler:

  __cond_resched+0x21/0x60
  down_timeout+0x18/0x60
  acpi_os_wait_semaphore+0x4c/0x80
  acpi_ut_acquire_mutex+0x3d/0x100
  acpi_ns_get_node+0x27/0x60
  acpi_ns_evaluate+0x1cb/0x2d0
  acpi_rs_set_srs_method_data+0x156/0x190
  acpi_pci_link_set+0x11c/0x290
  irqrouter_resume+0x54/0x60
  syscore_resume+0x6a/0x200
  kernel_kexec+0x145/0x1c0
  __do_sys_reboot+0xeb/0x240
  do_syscall_64+0x95/0x180

This is a long standing problem, which probably got more visible with
the recent printk changes. Something does a task wakeup and the
scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and
invokes schedule() from a completely bogus context. The scheduler
enables interrupts after context switching, which causes the above
warning at the end.

Quite some of the code paths in syscore_suspend()/resume() can result in
triggering a wakeup with the exactly same consequences. They might not
have done so yet, but as they share a lot of code with normal operations
it's just a question of time.

The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling
models. Full preemption is not affected as cond_resched() is disabled and
the preemption check preemptible() takes the interrupt disabled flag into
account.

Cure the problem by adding a corresponding check into cond_resched().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-03-27T14:57:02.886Z
CVE-2024-58091 drm/fbdev-dma: Add shadow buffering for deferred I/O
In the Linux kernel, the following vulnerability has been resolved:

drm/fbdev-dma: Add shadow buffering for deferred I/O

DMA areas are not necessarily backed by struct page, so we cannot
rely on it for deferred I/O. Allocate a shadow buffer for drivers
that require deferred I/O and use it as framebuffer memory.

Fixes driver errors about being "Unable to handle kernel NULL pointer
dereference at virtual address" or "Unable to handle kernel paging
request at virtual address".

The patch splits drm_fbdev_dma_driver_fbdev_probe() in an initial
allocation, which creates the DMA-backed buffer object, and a tail
that sets up the fbdev data structures. There is a tail function for
direct memory mappings and a tail function for deferred I/O with
the shadow buffer.

It is no longer possible to use deferred I/O without shadow buffer.
It can be re-added if there exists a reliably test for usable struct
page in the allocated DMA-backed buffer object.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-03-27T14:57:03.560Z
CVE-2024-58092 nfsd: fix legacy client tracking initialization
In the Linux kernel, the following vulnerability has been resolved:

nfsd: fix legacy client tracking initialization

Get rid of the nfsd4_legacy_tracking_ops->init() call in
check_for_legacy_methods().  That will be handled in the caller
(nfsd4_client_tracking_init()).  Otherwise, we'll wind up calling
nfsd4_legacy_tracking_ops->init() twice, and the second time we'll
trigger the BUG_ON() in nfsd4_init_recdir().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-04-16T10:24:53.056Z
CVE-2024-58093 PCI/ASPM: Fix link state exit during switch upstream function removal
In the Linux kernel, the following vulnerability has been resolved:

PCI/ASPM: Fix link state exit during switch upstream function removal

Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to
avoid use-after-free"), we would free the ASPM link only after the last
function on the bus pertaining to the given link was removed.

That was too late. If function 0 is removed before sibling function,
link->downstream would point to free'd memory after.

After above change, we freed the ASPM parent link state upon any function
removal on the bus pertaining to a given link.

That is too early. If the link is to a PCIe switch with MFD on the upstream
port, then removing functions other than 0 first would free a link which
still remains parent_link to the remaining downstream ports.

The resulting GPFs are especially frequent during hot-unplug, because
pciehp removes devices on the link bus in reverse order.

On that switch, function 0 is the virtual P2P bridge to the internal bus.
Free exactly when function 0 is removed -- before the parent link is
obsolete, but after all subordinate links are gone.

[kwilczynski: commit log]
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-04-16T14:11:42.682Z
CVE-2024-58094 jfs: add check read-only before truncation in jfs_truncate_nolock()
In the Linux kernel, the following vulnerability has been resolved:

jfs: add check read-only before truncation in jfs_truncate_nolock()

Added a check for "read-only" mode in the `jfs_truncate_nolock`
function to avoid errors related to writing to a read-only
filesystem.

Call stack:

block_write_begin() {
  jfs_write_failed() {
    jfs_truncate() {
      jfs_truncate_nolock() {
        txEnd() {
          ...
          log = JFS_SBI(tblk->sb)->log;
          // (log == NULL)

If the `isReadOnly(ip)` condition is triggered in
`jfs_truncate_nolock`, the function execution will stop, and no
further data modification will occur. Instead, the `xtTruncate`
function will be called with the "COMMIT_WMAP" flag, preventing
modifications in "read-only" mode.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-04-16T14:11:43.298Z
CVE-2024-58095 jfs: add check read-only before txBeginAnon() call
In the Linux kernel, the following vulnerability has been resolved:

jfs: add check read-only before txBeginAnon() call

Added a read-only check before calling `txBeginAnon` in `extAlloc`
and `extRecord`. This prevents modification attempts on a read-only
mounted filesystem, avoiding potential errors or crashes.

Call trace:
 txBeginAnon+0xac/0x154
 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78
 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248
 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128
 __block_write_begin fs/buffer.c:2177 [inline]
 block_write_begin+0x98/0x11c fs/buffer.c:2236
 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-04-16T14:11:43.934Z
CVE-2024-58096 wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode

ath11k_hal_srng_* should be used with srng->lock to protect srng data.

For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),
they use ath11k_hal_srng_* for many times but never call srng->lock.

So when running (full) monitor mode, warning will occur:
RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
Call Trace:
 ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]
 ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]
 ? idr_alloc_u32+0x97/0xd0
 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]
 ath11k_dp_service_srng+0x289/0x5a0 [ath11k]
 ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]
 __napi_poll+0x30/0x1f0
 net_rx_action+0x198/0x320
 __do_softirq+0xdd/0x319

So add srng->lock for them to avoid such warnings.

Inorder to fetch the srng->lock, should change srng's definition from
'void' to 'struct hal_srng'. And initialize them elsewhere to prevent
one line of code from being too long. This is consistent with other ring
process functions, such as ath11k_dp_process_rx().

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-04-16T14:11:44.587Z
CVE-2024-58097 wifi: ath11k: fix RCU stall while reaping monitor destination ring
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix RCU stall while reaping monitor destination ring

While processing the monitor destination ring, MSDUs are reaped from the
link descriptor based on the corresponding buf_id.

However, sometimes the driver cannot obtain a valid buffer corresponding
to the buf_id received from the hardware. This causes an infinite loop
in the destination processing, resulting in a kernel crash.

kernel log:
ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed
ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309
ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed

Fix this by skipping the problematic buf_id and reaping the next entry,
replacing the break with the next MSDU processing.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-04-16T14:11:45.330Z
CVE-2024-58098 bpf: track changes_pkt_data property for global functions
In the Linux kernel, the following vulnerability has been resolved:

bpf: track changes_pkt_data property for global functions

When processing calls to certain helpers, verifier invalidates all
packet pointers in a current state. For example, consider the
following program:

    __attribute__((__noinline__))
    long skb_pull_data(struct __sk_buff *sk, __u32 len)
    {
        return bpf_skb_pull_data(sk, len);
    }

    SEC("tc")
    int test_invalidate_checks(struct __sk_buff *sk)
    {
        int *p = (void *)(long)sk->data;
        if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP;
        skb_pull_data(sk, 0);
        *p = 42;
        return TCX_PASS;
    }

After a call to bpf_skb_pull_data() the pointer 'p' can't be used
safely. See function filter.c:bpf_helper_changes_pkt_data() for a list
of such helpers.

At the moment verifier invalidates packet pointers when processing
helper function calls, and does not traverse global sub-programs when
processing calls to global sub-programs. This means that calls to
helpers done from global sub-programs do not invalidate pointers in
the caller state. E.g. the program above is unsafe, but is not
rejected by verifier.

This commit fixes the omission by computing field
bpf_subprog_info->changes_pkt_data for each sub-program before main
verification pass.
changes_pkt_data should be set if:
- subprogram calls helper for which bpf_helper_changes_pkt_data
  returns true;
- subprogram calls a global function,
  for which bpf_subprog_info->changes_pkt_data should be set.

The verifier.c:check_cfg() pass is modified to compute this
information. The commit relies on depth first instruction traversal
done by check_cfg() and absence of recursive function calls:
- check_cfg() would eventually visit every call to subprogram S in a
  state when S is fully explored;
- when S is fully explored:
  - every direct helper call within S is explored
    (and thus changes_pkt_data is set if needed);
  - every call to subprogram S1 called by S was visited with S1 fully
    explored (and thus S inherits changes_pkt_data from S1).

The downside of such approach is that dead code elimination is not
taken into account: if a helper call inside global function is dead
because of current configuration, verifier would conservatively assume
that the call occurs for the purpose of the changes_pkt_data
computation.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-05-05T14:53:32.417Z
CVE-2024-58099 vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame
In the Linux kernel, the following vulnerability has been resolved:

vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame

Andrew and Nikolay reported connectivity issues with Cilium's service
load-balancing in case of vmxnet3.

If a BPF program for native XDP adds an encapsulation header such as
IPIP and transmits the packet out the same interface, then in case
of vmxnet3 a corrupted packet is being sent and subsequently dropped
on the path.

vmxnet3_xdp_xmit_frame() which is called e.g. via vmxnet3_run_xdp()
through vmxnet3_xdp_xmit_back() calculates an incorrect DMA address:

  page = virt_to_page(xdpf->data);
  tbi->dma_addr = page_pool_get_dma_addr(page) +
                  VMXNET3_XDP_HEADROOM;
  dma_sync_single_for_device(&adapter->pdev->dev,
                             tbi->dma_addr, buf_size,
                             DMA_TO_DEVICE);

The above assumes a fixed offset (VMXNET3_XDP_HEADROOM), but the XDP
BPF program could have moved xdp->data. While the passed buf_size is
correct (xdpf->len), the dma_addr needs to have a dynamic offset which
can be calculated as xdpf->data - (void *)xdpf, that is, xdp->data -
xdp->data_hard_start.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-04-29T11:45:30.997Z
CVE-2024-58100 bpf: check changes_pkt_data property for extension programs
In the Linux kernel, the following vulnerability has been resolved:

bpf: check changes_pkt_data property for extension programs

When processing calls to global sub-programs, verifier decides whether
to invalidate all packet pointers in current state depending on the
changes_pkt_data property of the global sub-program.

Because of this, an extension program replacing a global sub-program
must be compatible with changes_pkt_data property of the sub-program
being replaced.

This commit:
- adds changes_pkt_data flag to struct bpf_prog_aux:
  - this flag is set in check_cfg() for main sub-program;
  - in jit_subprogs() for other sub-programs;
- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;
- moves call to check_attach_btf_id() after the call to check_cfg(),
  because it needs changes_pkt_data flag to be set:

    bpf_check:
      ...                             ...
    - check_attach_btf_id             resolve_pseudo_ldimm64
      resolve_pseudo_ldimm64   -->    bpf_prog_is_offloaded
      bpf_prog_is_offloaded           check_cfg
      check_cfg                     + check_attach_btf_id
      ...                             ...

The following fields are set by check_attach_btf_id():
- env->ops
- prog->aux->attach_btf_trace
- prog->aux->attach_func_name
- prog->aux->attach_func_proto
- prog->aux->dst_trampoline
- prog->aux->mod
- prog->aux->saved_dst_attach_type
- prog->aux->saved_dst_prog_type
- prog->expected_attach_type

Neither of these fields are used by resolve_pseudo_ldimm64() or
bpf_prog_offload_verifier_prep() (for netronome and netdevsim
drivers), so the reordering is safe.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-05-05T14:53:33.445Z
CVE-2024-58101 
Samsung Galaxy Buds and Galaxy Buds 2 audio devices are Bluetooth pairable by default without user input nor a way to stop this mode. As a consequence, audio playback takeover or even microphone recording without user consent or notification is achieved. Note: This is considered a low severity vulnerability by the vendor.
Problem types: description: n/a
Affected products: vendor: n/a
product: n/a
Published: 2025-05-14T00:00:00.000Z
CVE-2024-58102 
An issue was discovered in Datalust Seq before 2024.3.13545. An insecure default parsing depth limit allows stack consumption when parsing user-supplied queries containing deeply nested expressions.
Problem types: cwe_id: CWE-674
description: CWE-674 Uncontrolled Recursion
Affected products: vendor: Datalust
product: Seq
default_status: unaffected
CVSS v3.1: version: 3.1
baseScore: 5.7
baseSeverity: MEDIUM
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C
Published: 2025-03-11T00:00:00.000Z
CVE-2024-58103 
Square Wire before 5.2.0 does not enforce a recursion limit on nested groups in ByteArrayProtoReader32.kt and ProtoReader.kt.
Problem types: cwe_id: CWE-674
description: CWE-674 Uncontrolled Recursion
Affected products: vendor: Square
product: Wire
default_status: unaffected
CVSS v3.1: version: 3.1
baseScore: 5.8
baseSeverity: MEDIUM
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L
Published: 2025-03-16T00:00:00.000Z
CVE-2024-58104 
A vulnerability  in the Trend Micro Apex One Security Agent Plug-in User Interface Manager could allow a local attacker to bypass existing security and execute arbitrary code on affected installations. 

Please note: an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
Affected products: vendor: Trend Micro, Inc.
product: Trend Micro Apex One
vendor: Trend Micro, Inc.
product: Trend Micro Apex One as a Service
CVSS v3.1: version: 3.1
attackVector: LOCAL
attackComplexity: LOW
privilegesRequired: LOW
userInteraction: REQUIRED
scope: UNCHANGED
confidentialityImpact: HIGH
integrityImpact: HIGH
availabilityImpact: HIGH
baseSeverity: HIGH
baseScore: 7.3
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Published: 2025-03-25T17:37:28.783Z
CVE-2024-58105 
A vulnerability  in the Trend Micro Apex One Security Agent Plug-in User Interface Manager could allow a local attacker to bypass existing security and execute arbitrary code on affected installations. 

This CVE address an addtional bypass not covered in CVE-2024-58104.

Please note: an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
Affected products: vendor: Trend Micro, Inc.
product: Trend Micro Apex One
vendor: Trend Micro, Inc.
product: Trend Micro Apex One as a Service
CVSS v3.1: version: 3.1
attackVector: LOCAL
attackComplexity: LOW
privilegesRequired: LOW
userInteraction: REQUIRED
scope: UNCHANGED
confidentialityImpact: HIGH
integrityImpact: HIGH
availabilityImpact: HIGH
baseSeverity: HIGH
baseScore: 7.3
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Published: 2025-03-25T17:37:39.464Z
CVE-2024-58106 
Buffer overflow vulnerability in the codec module
Impact: Successful exploitation of this vulnerability may affect availability.
Problem types: cwe_id: CWE-120
description: CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: ADJACENT_NETWORK
availabilityImpact: LOW
baseScore: 4.6
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L
version: 3.1
Published: 2025-04-07T03:31:45.797Z
CVE-2024-58107 
Buffer overflow vulnerability in the codec 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: NETWORK
availabilityImpact: NONE
baseScore: 7.5
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
version: 3.1
Published: 2025-04-07T03:33:15.998Z
CVE-2024-58108 
Buffer overflow vulnerability in the codec module
Impact: Successful exploitation of this vulnerability may affect availability.
Problem types: cwe_id: CWE-120
description: CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: ADJACENT_NETWORK
availabilityImpact: LOW
baseScore: 4.6
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L
version: 3.1
Published: 2025-04-07T03:34:16.940Z
CVE-2024-58109 
Buffer overflow vulnerability in the codec module
Impact: Successful exploitation of this vulnerability may affect availability.
Problem types: cwe_id: CWE-120
description: CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: ADJACENT_NETWORK
availabilityImpact: LOW
baseScore: 4.6
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L
version: 3.1
Published: 2025-04-07T03:35:12.667Z
CVE-2024-58110 
Buffer overflow vulnerability in the codec module
Impact: Successful exploitation of this vulnerability may affect availability.
Problem types: cwe_id: CWE-120
description: CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: ADJACENT_NETWORK
availabilityImpact: LOW
baseScore: 4.6
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L
version: 3.1
Published: 2025-04-07T03:36:06.556Z
CVE-2024-58111 
Exception capture failure vulnerability in the SVG parsing module of the ArkUI framework
Impact: Successful exploitation of this vulnerability may affect availability.
Problem types: cwe_id: CWE-248
description: CWE-248 Uncaught Exception
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: HIGH
baseScore: 7.5
baseSeverity: HIGH
confidentialityImpact: NONE
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
version: 3.1
Published: 2025-04-07T03:37:11.430Z
CVE-2024-58112 
Exception capture failure vulnerability in the SVG parsing module of the ArkUI framework
Impact: Successful exploitation of this vulnerability may affect availability.
Problem types: cwe_id: CWE-248
description: CWE-248 Uncaught Exception
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: HIGH
baseScore: 7.5
baseSeverity: HIGH
confidentialityImpact: NONE
integrityImpact: NONE
privilegesRequired: NONE
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
version: 3.1
Published: 2025-04-07T03:37:59.179Z