Concurrent variable access vulnerability in the ability module Impact: Successful exploitation of this vulnerability may affect availability.

Race condition vulnerability in the binder driver module Impact: Successful exploitation of this vulnerability will affect availability.

Race condition vulnerability in the kernel network module Impact:Successful exploitation of this vulnerability may affect availability.

Race condition vulnerability in the kernel file system module. Impact: Successful exploitation of this vulnerability may affect availability.

A memory buffer error vulnerability exists in a component interface of Huawei Smartphone. Local attackers can exploit this vulnerability to cause memory leakage and doS attacks by carefully constructing attack scenarios.

The TrustZone driver in Huawei P9 phones with software Versions earlier than EVA-AL10C00B352 and P9 Lite with software VNS-L21C185B130 and earlier versions and P8 Lite with software ALE-L02C636B150 and earlier versions has an input validation vulnerability, which allows attackers to cause the system to restart.

Huawei eSpace Desktop before V100R001C03 allows local users to cause a denial of service (program exit) via a crafted QES file.

There is a Race Condition vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to motionhub crash.

Race condition vulnerability in the kernel hufs module. Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Location-related APIs exists a Race Condition vulnerability.Successful exploitation of this vulnerability may use Higher Permissions for invoking the interface of location-related components.

There is a Race Condition vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to availability affected.

Race condition issue occurring in the physical page import process of the memory management module. Impact: Successful exploitation of this vulnerability may affect service integrity.

There is a issue that nodes in the linked list being freed for multiple times in Huawei Smartphone due to race conditions. Successful exploitation of this vulnerability can cause the system to restart.

There is a Race Condition vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to the user root privilege escalation.

There is a Encoding timing vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to denial of service.

Race condition vulnerability in the soundtrigger module Impact: Successful exploitation of this vulnerability will affect availability.

Race condition vulnerability in the Wi-Fi module. Impact: Successful exploitation of this vulnerability will affect availability.

The iaware module has a vulnerability in thread security. Successful exploitation of this vulnerability will affect confidentiality, integrity, and availability.

There is a race condition vulnerability in SD upgrade mode. Successful exploitation of this vulnerability may affect data confidentiality.

Vulnerability of mutex management in the bone voice ID trusted application (TA) module. Successful exploitation of this vulnerability may cause the bone voice ID feature to be unavailable.

There is a race condition vulnerability in eCNS280_TD V100R005C00 and V100R005C10. There is a timing window exists in which the database can be operated by another thread that is operating concurrently. Successful exploit may cause the affected device abnormal.

There is an Incomplete Cleanup Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to authentication bypass.

There is a multiple threads race condition vulnerability in Huawei product. A race condition exists for concurrent I/O read by multiple threads. An attacker with the root permission can exploit this vulnerability by performing some operations. Successful exploitation of this vulnerability may cause the system to crash. Affected product versions include: ManageOne 6.5.1.SPC200, 8.0.0,8.0.0-LCND81, 8.0.0.SPC100, 8.0.1,8.0.RC2, 8.0.RC3, 8.0.RC3.SPC100;SMC2.0 V600R019C10SPC700,V600R019C10SPC702, V600R019C10SPC703,V600R019C10SPC800, V600R019C10SPC900, V600R019C10SPC910, V600R019C10SPC920, V600R019C10SPC921, V600R019C10SPC922, V600R019C10SPC930, V600R019C10SPC931

There is a Heap-based Buffer Overflow Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to authentication bypass.

There is an Information Disclosure Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to authentication bypass.

Audio driver in P9 smartphones with software The versions before EVA-AL10C00B389 has a denial of service (DoS) vulnerability. An attacker tricks a user into installing a malicious application on the smart phone, and the race condition cause null pointer accessing during the application access shared resource, which make the system reboot.

The MPTCP module has the race condition vulnerability. Successful exploitation of this vulnerability may cause the device to restart.

Multi-concurrency vulnerability in the media digital copyright protection module Impact: Successful exploitation of this vulnerability may affect availability.

Multi-thread problem vulnerability in the package management module Impact: Successful exploitation of this vulnerability may affect availability.

Race condition vulnerability in the Bastet module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

Race condition vulnerability in the distributed notification module Impact: Successful exploitation of this vulnerability may cause features to perform abnormally.

Race condition vulnerability in the DDR module Impact: Successful exploitation of this vulnerability may affect service confidentiality.

The kernel module has the race condition vulnerability. Successful exploitation of this vulnerability may affect data confidentiality.

Huawei NIP6800 versions V500R001C30, V500R001C60SPC500, and V500R005C00; Secospace USG6600 and USG9500 versions V500R001C30SPC200, V500R001C30SPC600, V500R001C60SPC500, and V500R005C00 have a Dangling pointer dereference vulnerability. An authenticated attacker may do some special operations in the affected products in some special scenarios to exploit the vulnerability. Due to improper race conditions of different operations, successful exploit will lead to Dangling pointer dereference, causing some service abnormal.

The Gallery app has the risk of hijacking attacks. Successful exploitation of this vulnerability may cause download failures and affect product availability.

Certain detection module of P30, P30 Pro, Honor V20 smartphone whith Versions earlier than ELLE-AL00B 9.1.0.193(C00E190R1P21), Versions earlier than VOGUE-AL00A 9.1.0.193(C00E190R1P12), Versions earlier than Princeton-AL10B 9.1.0.233(C00E233R4P3) have a race condition vulnerability. The system does not lock certain function properly, when the function is called by multiple processes could cause out of bound write. An attacker tricks the user into installing a malicious application, successful exploit could cause malicious code execution.

There is a race condition vulnerability on Huawei Honor V10 smartphones versions earlier than Berkeley-AL20 9.0.0.156(C00E156R2P14T8), Honor 10 smartphones versions earlier than Columbia-AL10B 9.0.0.156(C00E156R1P20T8) and Honor Play smartphones versions earlier than Cornell-AL00A 9.0.0.156(C00E156R1P13T8). An attacker tricks the user into installing a malicious application, which makes multiple processes to operate the same variate at the same time. Successful exploit could cause execution of malicious code.

There is a Race Condition vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may lead to the detection result is tampered with.

There is a issue that trustlist strings being repeatedly inserted into the linked list in Huawei Smartphone due to race conditions. Successful exploitation of this vulnerability can cause exceptions when managing the system trustlist.

Out-of-bounds access vulnerability in the memory module Impact: Successful exploitation of this vulnerability will affect availability.

Race condition vulnerability in the kernel module. Successful exploitation of this vulnerability may cause variable values to be read with the condition evaluation bypassed.

Race condition vulnerability due to multi-thread access to mutually exclusive resources in Huawei Share. Successful exploitation of this vulnerability may cause the program to exit abnormally.

HUAWEI Mate 30 with versions earlier than 10.1.0.150(C00E136R5P3) have a race condition vulnerability. There is a timing window exists in which certain pointer members can be modified by another process that is operating concurrently, an attacker should trick the user into running a crafted application with high privilege, successful exploit could cause code execution.

A race condition in Intel(R) Graphics Drivers before version 10.18.14.5067 (aka 15.36.x.5067) and 10.18.10.5069 (aka 15.33.x.5069) may allow an authenticated user to potentially enable a denial of service via local access.

Race condition in the tty_fasync function in drivers/char/tty_io.c in the Linux kernel before 2.6.32.6 allows local users to cause a denial of service (NULL pointer dereference and system crash) or possibly have unspecified other impact via unknown vectors, related to the put_tty_queue and __f_setown functions. NOTE: the vulnerability was addressed in a different way in 2.6.32.9.

A race problem was found in fs/proc/task_mmu.c in the memory management sub-component in the Linux kernel. This issue may allow a local attacker with user privilege to cause a denial of service.

In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback.

In the Linux kernel, the following vulnerability has been resolved: wireguard: receive: annotate data-race around receiving_counter.counter Syzkaller with KCSAN identified a data-race issue when accessing keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE() annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ...

In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.

In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue.