rainbutterfly/cve_corpus huggingface dataset:
CVE-2023-52513 RDMA/siw: Fix connection failure handling
In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Fix connection failure handling

In case immediate MPA request processing fails, the newly
created endpoint unlinks the listening endpoint and is
ready to be dropped. This special case was not handled
correctly by the code handling the later TCP socket close,
causing a NULL dereference crash in siw_cm_work_handler()
when dereferencing a NULL listener. We now also cancel
the useless MPA timeout, if immediate MPA request
processing fails.

This patch furthermore simplifies MPA processing in general:
Scheduling a useless TCP socket read in sk_data_ready() upcall
is now surpressed, if the socket is already moved out of
TCP_ESTABLISHED state.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:24.587Z
CVE-2023-52515 RDMA/srp: Do not call scsi_done() from srp_abort()
In the Linux kernel, the following vulnerability has been resolved:

RDMA/srp: Do not call scsi_done() from srp_abort()

After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
callback, it performs one of the following actions:
* Call scsi_queue_insert().
* Call scsi_finish_command().
* Call scsi_eh_scmd_add().
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
the above actions would trigger a use-after-free. Hence remove the
scsi_done() call from srp_abort(). Keep the srp_free_req() call
before returning SUCCESS because we may not see the command again if
SUCCESS is returned.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:25.863Z
CVE-2023-52517 spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain
In the Linux kernel, the following vulnerability has been resolved:

spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain

Previously the transfer complete IRQ immediately drained to RX FIFO to
read any data remaining in FIFO to the RX buffer. This behaviour is
correct when dealing with SPI in interrupt mode. However in DMA mode the
transfer complete interrupt still fires as soon as all bytes to be
transferred have been stored in the FIFO. At that point data in the FIFO
still needs to be picked up by the DMA engine. Thus the drain procedure
and DMA engine end up racing to read from RX FIFO, corrupting any data
read. Additionally the RX buffer pointer is never adjusted according to
DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA
mode is a bug.
Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode.
Also wait for completion of RX DMA when in DMA mode before returning to
ensure all data has been copied to the supplied memory buffer.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:27.152Z
CVE-2023-52518 Bluetooth: hci_codec: Fix leaking content of local_codecs
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_codec: Fix leaking content of local_codecs

The following memory leak can be observed when the controller supports
codecs which are stored in local_codecs list but the elements are never
freed:

unreferenced object 0xffff88800221d840 (size 32):
  comm "kworker/u3:0", pid 36, jiffies 4294898739 (age 127.060s)
  hex dump (first 32 bytes):
    f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff  ..........!.....
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffffb324f557>] __kmalloc+0x47/0x120
    [<ffffffffb39ef37d>] hci_codec_list_add.isra.0+0x2d/0x160
    [<ffffffffb39ef643>] hci_read_codec_capabilities+0x183/0x270
    [<ffffffffb39ef9ab>] hci_read_supported_codecs+0x1bb/0x2d0
    [<ffffffffb39f162e>] hci_read_local_codecs_sync+0x3e/0x60
    [<ffffffffb39ff1b3>] hci_dev_open_sync+0x943/0x11e0
    [<ffffffffb396d55d>] hci_power_on+0x10d/0x3f0
    [<ffffffffb30c99b4>] process_one_work+0x404/0x800
    [<ffffffffb30ca134>] worker_thread+0x374/0x670
    [<ffffffffb30d9108>] kthread+0x188/0x1c0
    [<ffffffffb304db6b>] ret_from_fork+0x2b/0x50
    [<ffffffffb300206a>] ret_from_fork_asm+0x1a/0x30
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:54:47.826Z
CVE-2023-52519 HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit
In the Linux kernel, the following vulnerability has been resolved:

HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit

The EHL (Elkhart Lake) based platforms provide a OOB (Out of band)
service, which allows to wakup device when the system is in S5 (Soft-Off
state). This OOB service can be enabled/disabled from BIOS settings. When
enabled, the ISH device gets PME wake capability. To enable PME wakeup,
driver also needs to enable ACPI GPE bit.

On resume, BIOS will clear the wakeup bit. So driver need to re-enable it
in resume function to keep the next wakeup capability. But this BIOS
clearing of wakeup bit doesn't decrement internal OS GPE reference count,
so this reenabling on every resume will cause reference count to overflow.

So first disable and reenable ACPI GPE bit using acpi_disable_gpe().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:27.816Z
CVE-2023-52520 platform/x86: think-lmi: Fix reference leak
In the Linux kernel, the following vulnerability has been resolved:

platform/x86: think-lmi: Fix reference leak

If a duplicate attribute is found using kset_find_obj(), a reference
to that attribute is returned which needs to be disposed accordingly
using kobject_put(). Move the setting name validation into a separate
function to allow for this change without having to duplicate the
cleanup code for this setting.
As a side note, a very similar bug was fixed in
commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"),
so it seems that the bug was copied from that driver.

Compile-tested only.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:28.434Z
CVE-2023-52522 net: fix possible store tearing in neigh_periodic_work()
In the Linux kernel, the following vulnerability has been resolved:

net: fix possible store tearing in neigh_periodic_work()

While looking at a related syzbot report involving neigh_periodic_work(),
I found that I forgot to add an annotation when deleting an
RCU protected item from a list.

Readers use rcu_deference(*np), we need to use either
rcu_assign_pointer() or WRITE_ONCE() on writer side
to prevent store tearing.

I use rcu_assign_pointer() to have lockdep support,
this was the choice made in neigh_flush_dev().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:29.710Z
CVE-2023-52523 bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets
In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets

With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages
sent from one TCP socket (s1) to actually egress from another TCP
socket (s2):

tcp_bpf_sendmsg(s1)		// = sk_prot->sendmsg
  tcp_bpf_send_verdict(s1)	// __SK_REDIRECT case
    tcp_bpf_sendmsg_redir(s2)
      tcp_bpf_push_locked(s2)
	tcp_bpf_push(s2)
	  tcp_rate_check_app_limited(s2) // expects tcp_sock
	  tcp_sendmsg_locked(s2)	 // ditto

There is a hard-coded assumption in the call-chain, that the egress
socket (s2) is a TCP socket.

However in commit 122e6c79efe1 ("sock_map: Update sock type checks for
UDP") we have enabled redirects to non-TCP sockets. This was done for the
sake of BPF sk_skb programs. There was no indention to support sk_msg
send-to-egress use case.

As a result, attempts to send-to-egress through a non-TCP socket lead to a
crash due to invalid downcast from sock to tcp_sock:

 BUG: kernel NULL pointer dereference, address: 000000000000002f
 ...
 Call Trace:
  <TASK>
  ? show_regs+0x60/0x70
  ? __die+0x1f/0x70
  ? page_fault_oops+0x80/0x160
  ? do_user_addr_fault+0x2d7/0x800
  ? rcu_is_watching+0x11/0x50
  ? exc_page_fault+0x70/0x1c0
  ? asm_exc_page_fault+0x27/0x30
  ? tcp_tso_segs+0x14/0xa0
  tcp_write_xmit+0x67/0xce0
  __tcp_push_pending_frames+0x32/0xf0
  tcp_push+0x107/0x140
  tcp_sendmsg_locked+0x99f/0xbb0
  tcp_bpf_push+0x19d/0x3a0
  tcp_bpf_sendmsg_redir+0x55/0xd0
  tcp_bpf_send_verdict+0x407/0x550
  tcp_bpf_sendmsg+0x1a1/0x390
  inet_sendmsg+0x6a/0x70
  sock_sendmsg+0x9d/0xc0
  ? sockfd_lookup_light+0x12/0x80
  __sys_sendto+0x10e/0x160
  ? syscall_enter_from_user_mode+0x20/0x60
  ? __this_cpu_preempt_check+0x13/0x20
  ? lockdep_hardirqs_on+0x82/0x110
  __x64_sys_sendto+0x1f/0x30
  do_syscall_64+0x38/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd

Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg
program to prevent the crash. When attempted, user will receive an EACCES
error from send/sendto/sendmsg() syscall.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:30.351Z
CVE-2023-52524 net: nfc: llcp: Add lock when modifying device list
In the Linux kernel, the following vulnerability has been resolved:

net: nfc: llcp: Add lock when modifying device list

The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:30.995Z
CVE-2023-52525 wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet
In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet

Only skip the code path trying to access the rfc1042 headers when the
buffer is too small, so the driver can still process packets without
rfc1042 headers.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: unaffected
Published: 2024-03-02T21:52:31.638Z
CVE-2023-52526 erofs: fix memory leak of LZMA global compressed deduplication
In the Linux kernel, the following vulnerability has been resolved:

erofs: fix memory leak of LZMA global compressed deduplication

When stressing microLZMA EROFS images with the new global compressed
deduplication feature enabled (`-Ededupe`), I found some short-lived
temporary pages weren't properly released, which could slowly cause
unexpected OOMs hours later.

Let's fix it now (LZ4 and DEFLATE don't have this issue.)
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:32.261Z
CVE-2023-52527 ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()
In the Linux kernel, the following vulnerability has been resolved:

ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()

Including the transhdrlen in length is a problem when the packet is
partially filled (e.g. something like send(MSG_MORE) happened previously)
when appending to an IPv4 or IPv6 packet as we don't want to repeat the
transport header or account for it twice.  This can happen under some
circumstances, such as splicing into an L2TP socket.

The symptom observed is a warning in __ip6_append_data():

    WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800

that occurs when MSG_SPLICE_PAGES is used to append more data to an already
partially occupied skbuff.  The warning occurs when 'copy' is larger than
the amount of data in the message iterator.  This is because the requested
length includes the transport header length when it shouldn't.  This can be
triggered by, for example:

        sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);
        bind(sfd, ...); // ::1
        connect(sfd, ...); // ::1 port 7
        send(sfd, buffer, 4100, MSG_MORE);
        sendfile(sfd, dfd, NULL, 1024);

Fix this by only adding transhdrlen into the length if the write queue is
empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.

l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds
the UDP packet itself.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:32.890Z
CVE-2023-52529 HID: sony: Fix a potential memory leak in sony_probe()
In the Linux kernel, the following vulnerability has been resolved:

HID: sony: Fix a potential memory leak in sony_probe()

If an error occurs after a successful usb_alloc_urb() call, usb_free_urb()
should be called.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:34.217Z
CVE-2023-52530 wifi: mac80211: fix potential key use-after-free
In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix potential key use-after-free

When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add().
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:34.966Z
CVE-2023-52531 wifi: iwlwifi: mvm: Fix a memory corruption issue
In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: Fix a memory corruption issue

A few lines above, space is kzalloc()'ed for:
	sizeof(struct iwl_nvm_data) +
	sizeof(struct ieee80211_channel) +
	sizeof(struct ieee80211_rate)

'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine.

At the end of this structure, there is the 'channels' flex array.
Each element is of type 'struct ieee80211_channel'.
So only 1 element is allocated in this array.

When doing:
  mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels;
We point at the first element of the 'channels' flex array.
So this is fine.

However, when doing:
  mvm->nvm_data->bands[0].bitrates =
			(void *)((u8 *)mvm->nvm_data->channels + 1);
because of the "(u8 *)" cast, we add only 1 to the address of the beginning
of the flex array.

It is likely that we want point at the 'struct ieee80211_rate' allocated
just after.

Remove the spurious casting so that the pointer arithmetic works as
expected.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:35.664Z
CVE-2023-52532 net: mana: Fix TX CQE error handling
In the Linux kernel, the following vulnerability has been resolved:

net: mana: Fix TX CQE error handling

For an unknown TX CQE error type (probably from a newer hardware),
still free the SKB, update the queue tail, etc., otherwise the
accounting will be wrong.

Also, TX errors can be triggered by injecting corrupted packets, so
replace the WARN_ONCE to ratelimited error logging.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2024-03-02T21:52:36.292Z
CVE-2023-52533 
In modem-ps-nas-ngmm, there is a possible undefined behavior due to incorrect error handling. This could lead to remote information disclosure no additional execution privileges needed
Affected products: vendor: Unisoc (Shanghai) Technologies Co., Ltd.
product: T760/T770/T820/S8000
default_status: unaffected
Published: 2024-04-08T02:21:39.692Z
CVE-2023-52534 
In ngmm, there is a possible undefined behavior due to incorrect error handling. This could lead to remote denial of service with no additional execution privileges needed
Affected products: vendor: Unisoc (Shanghai) Technologies Co., Ltd.
product: T760/T770/T820/S8000
default_status: unaffected
Published: 2024-04-08T02:21:39.957Z
CVE-2023-52535 
In vsp driver, there is a possible missing verification incorrect input. This could lead to local denial of service with no additional execution privileges needed
Affected products: vendor: Unisoc (Shanghai) Technologies Co., Ltd.
product: SC7731E/SC9832E/SC9863A/T310/T610/T618
default_status: unaffected
Published: 2024-04-08T02:21:40.221Z
CVE-2023-52536 
In faceid service, there is a possible out of bounds read due to a missing bounds check. This could lead to local denial of service with System execution privileges needed
Affected products: vendor: Unisoc (Shanghai) Technologies Co., Ltd.
product: SC7731E/SC9832E/SC9863A/T310/T606/T612/T616/T610/T618/T760/T770/T820/S8000
default_status: unaffected
Published: 2024-04-08T02:21:40.495Z
CVE-2023-52537 
Vulnerability of package name verification being bypassed in the HwIms module.
Impact: Successful exploitation of this vulnerability will affect availability.
Problem types: description: Permissions, Privileges, and Access Controls
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:40:37.167Z
CVE-2023-52538 
Vulnerability of package name verification being bypassed in the HwIms module.
Impact: Successful exploitation of this vulnerability will affect availability.
Problem types: description: Permissions, Privileges, and Access Controls
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:43:01.514Z
CVE-2023-52539 
Permission verification vulnerability in the Settings module.
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
Problem types: description: Configuration
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:45:14.929Z
CVE-2023-52540 
Vulnerability of improper authentication in the Iaware module.
Impact: Successful exploitation of this vulnerability will affect availability.
Problem types: description: Permissions, Privileges, and Access Controls
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:46:23.790Z
CVE-2023-52541 
Authentication vulnerability in the API for app pre-loading.
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
Problem types: description: Permissions, Privileges, and Access Controls
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:47:29.919Z
CVE-2023-52542 
Permission verification vulnerability in the system module.
Impact: Successful exploitation of this vulnerability will affect availability.
Problem types: description: Permissions, Privileges, and Access Controls
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:48:33.106Z
CVE-2023-52543 
Permission verification vulnerability in the system module.
Impact: Successful exploitation of this vulnerability will affect availability.
Problem types: cwe_id: CWE-269
description: CWE-269 Improper Privilege Management
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:49:44.807Z
CVE-2023-52544 
Vulnerability of file path verification being bypassed in the email module.
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
Problem types: cwe_id: CWE-22
description: CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:52:13.485Z
CVE-2023-52545 
Vulnerability of undefined permissions in the Calendar app.
Impact: Successful exploitation of this vulnerability will affect availability.
Problem types: description: Permissions, Privileges, and Access Controls
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:53:09.751Z
CVE-2023-52546 
Vulnerability of package name verification being bypassed in the Calendar app.
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
Problem types: description: Permissions, Privileges, and Access Controls
Affected products: vendor: Huawei
product: HarmonyOS
default_status: unaffected
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:54:05.956Z
CVE-2023-52547 
Huawei Matebook D16(Model: CREM-WXX9, BIOS: v2.26. Memory Corruption in SMI Handler of HddPassword SMM Module. This can be leveraged by a malicious OS attacker to corrupt data structures stored at the beginning of SMRAM and can potentially lead to code execution in SMM.
Problem types: cwe_id: CWE-130
description: CWE-130 Improper Handling of Length Parameter Inconsistency
Affected products: vendor: Huawei
product: CurieM-WFG9B
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: HIGH
baseScore: 7.8
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Published: 2024-05-28T06:15:20.883Z
CVE-2023-52548 
Huawei Matebook D16(Model: CREM-WXX9, BIOS: v2.26) Arbitrary Memory Corruption in SMI Handler of ThisiServicesSmm SMM module. This can be leveraged by a malicious OS attacker to corrupt arbitrary SMRAM memory and, in turn, lead to code execution in SMM
Problem types: cwe_id: CWE-119
description: CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer
Affected products: vendor: Huawei
product: CurieM-WFG9B
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: LOCAL
availabilityImpact: HIGH
baseScore: 7.8
baseSeverity: HIGH
confidentialityImpact: HIGH
integrityImpact: HIGH
privilegesRequired: LOW
scope: UNCHANGED
userInteraction: NONE
vectorString: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
version: 3.1
Published: 2024-05-28T06:16:48.525Z
CVE-2023-52549 
Vulnerability of data verification errors in the kernel module.
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
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
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:55:11.618Z
CVE-2023-52550 
Vulnerability of data verification errors in the kernel module.
Impact: Successful exploitation of this vulnerability may affect service confidentiality.
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
vendor: Huawei
product: EMUI
default_status: unaffected
Published: 2024-04-08T08:56:22.568Z