Total
1904 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-52517 | 1 Linux | 1 Linux Kernel | 2025-01-13 | 7.0 High |
| 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. | ||||
| CVE-2023-52480 | 1 Linux | 1 Linux Kernel | 2025-01-13 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix race condition between session lookup and expire Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | + This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session. | ||||
| CVE-2023-52478 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-10 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- | ||||
| CVE-2023-33974 | 1 Riot-os | 1 Riot | 2025-01-10 | 7.5 High |
| RIOT-OS, an operating system for Internet of Things (IoT) devices, contains a network stack with the ability to process 6LoWPAN frames. In versions 2023.01 and prior, an attacker can send multiple crafted frames to the device to trigger a race condition. The race condition invalidates assumptions about the program state and leads to an invalid memory access resulting in denial of service. This issue is patched in pull request 19679. There are no known workarounds. | ||||
| CVE-2021-47069 | 2 Linux, Redhat | 6 Linux Kernel, Enterprise Linux, Rhel Aus and 3 more | 2025-01-09 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send. This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash: RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343 The race occurs as: 1. do_mq_timedreceive calls wq_sleep with the address of `struct ext_wait_queue` on function stack (aliased as `ewq_addr` here) - it holds a valid `struct ext_wait_queue *` as long as the stack has not been overwritten. 2. `ewq_addr` gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op. 3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (`this` is `ewq_addr`.) 4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see `state == STATE_READY` and break. 5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed to be a `struct ext_wait_queue *` since it was on do_mq_timedreceive's stack. (Although the address may not get overwritten until another function happens to touch it, which means it can persist around for an indefinite time.) 6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a `struct ext_wait_queue *`, and uses it to find a task_struct to pass to the wake_q_add_safe call. In the lucky case where nothing has overwritten `ewq_addr` yet, `ewq_addr->task` is the right task_struct. In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a bogus address as the receiver's task_struct causing the crash. do_mq_timedsend::__pipelined_op() should not dereference `this` after setting STATE_READY, as the receiver counterpart is now free to return. Change __pipelined_op to call wake_q_add_safe on the receiver's task_struct returned by get_task_struct, instead of dereferencing `this` which sits on the receiver's stack. As Manfred pointed out, the race potentially also exists in ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix those in the same way. | ||||
| CVE-2023-29537 | 1 Mozilla | 2 Firefox, Focus | 2025-01-09 | 7.5 High |
| Multiple race conditions in the font initialization could have led to memory corruption and execution of attacker-controlled code. This vulnerability affects Firefox for Android < 112, Firefox < 112, and Focus for Android < 112. | ||||
| CVE-2024-30046 | 2 Microsoft, Redhat | 3 .net, Visual Studio 2022, Enterprise Linux | 2025-01-08 | 5.9 Medium |
| Visual Studio Denial of Service Vulnerability | ||||
| CVE-2023-6109 | 1 Yop-poll | 1 Yop Poll | 2025-01-08 | 5.3 Medium |
| The YOP Poll plugin for WordPress is vulnerable to a race condition in all versions up to, and including, 6.5.26. This is due to improper restrictions on the add() function. This makes it possible for unauthenticated attackers to place multiple votes on a single poll even when the poll is set to one vote per person. | ||||
| CVE-2024-30031 | 1 Microsoft | 16 Windows, Windows 10 1507, Windows 10 1607 and 13 more | 2025-01-08 | 7.8 High |
| Windows CNG Key Isolation Service Elevation of Privilege Vulnerability | ||||
| CVE-2023-20736 | 3 Google, Linuxfoundation, Mediatek | 23 Android, Iot-yocto, Yocto and 20 more | 2025-01-07 | 6.4 Medium |
| In vcu, there is a possible out of bounds write due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07645149; Issue ID: ALPS07645189. | ||||
| CVE-2023-20750 | 2 Google, Mediatek | 23 Android, Mt6835, Mt6886 and 20 more | 2025-01-07 | 4.1 Medium |
| In swpm, there is a possible out of bounds write due to a race condition. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07780926; Issue ID: ALPS07780928. | ||||
| CVE-2023-52749 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2025-01-06 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: spi: Fix null dereference on suspend A race condition exists where a synchronous (noqueue) transfer can be active during a system suspend. This can cause a null pointer dereference exception to occur when the system resumes. Example order of events leading to the exception: 1. spi_sync() calls __spi_transfer_message_noqueue() which sets ctlr->cur_msg 2. Spi transfer begins via spi_transfer_one_message() 3. System is suspended interrupting the transfer context 4. System is resumed 6. spi_controller_resume() calls spi_start_queue() which resets cur_msg to NULL 7. Spi transfer context resumes and spi_finalize_current_message() is called which dereferences cur_msg (which is now NULL) Wait for synchronous transfers to complete before suspending by acquiring the bus mutex and setting/checking a suspend flag. | ||||
| CVE-2022-41035 | 1 Microsoft | 1 Edge Chromium | 2025-01-02 | 5.3 Medium |
| Microsoft Edge (Chromium-based) Spoofing Vulnerability | ||||
| CVE-2022-38047 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2025-01-02 | 8.1 High |
| Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability | ||||
| CVE-2022-38029 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2025-01-02 | 7 High |
| Windows ALPC Elevation of Privilege Vulnerability | ||||
| CVE-2022-38027 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2025-01-02 | 7 High |
| Windows Storage Elevation of Privilege Vulnerability | ||||
| CVE-2022-38021 | 1 Microsoft | 6 Windows 10, Windows 11, Windows Server 2012 and 3 more | 2025-01-02 | 7 High |
| Connected User Experiences and Telemetry Elevation of Privilege Vulnerability | ||||
| CVE-2022-38000 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2025-01-02 | 8.1 High |
| Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability | ||||
| CVE-2022-33634 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2025-01-02 | 8.1 High |
| Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability | ||||
| CVE-2022-30198 | 1 Microsoft | 10 Windows 10, Windows 11, Windows 7 and 7 more | 2025-01-02 | 8.1 High |
| Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability | ||||