Total
31934 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2023-28568 | 1 Qualcomm | 176 Aqt1000, Aqt1000 Firmware, Fastconnect 6200 and 173 more | 2024-04-12 | N/A | 5.5 MEDIUM |
| Information disclosure in WLAN HAL when reception status handler is called. | |||||
| CVE-2023-28584 | 1 Qualcomm | 144 Aqt1000, Aqt1000 Firmware, Csrb31024 and 141 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS in WLAN Host when a mobile station receives invalid channel in CSA IE while doing channel switch announcement (CSA). | |||||
| CVE-2023-33019 | 1 Qualcomm | 164 205, 205 Firmware, 215 and 161 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS in WLAN Host while doing channel switch announcement (CSA), when a mobile station receives invalid channel in CSA IE. | |||||
| CVE-2023-28553 | 1 Qualcomm | 288 Ar8035, Ar8035 Firmware, Ar9380 and 285 more | 2024-04-12 | N/A | 5.5 MEDIUM |
| Information Disclosure in WLAN Host when processing WMI event command. | |||||
| CVE-2023-33020 | 1 Qualcomm | 164 205, 205 Firmware, 215 and 161 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS in WLAN Host when an invalid channel (like channel out of range) is received in STA during CSA IE. | |||||
| CVE-2023-21641 | 1 Qualcomm | 30 Fastconnect 6900, Fastconnect 6900 Firmware, Fastconnect 7800 and 27 more | 2024-04-12 | N/A | 7.8 HIGH |
| An app with non-privileged access can change global system brightness and cause undesired system behavior. | |||||
| CVE-2023-21624 | 1 Qualcomm | 134 Fastconnect 6700, Fastconnect 6700 Firmware, Fastconnect 6800 and 131 more | 2024-04-12 | N/A | 5.5 MEDIUM |
| Information disclosure in DSP Services while loading dynamic module. | |||||
| CVE-2023-22382 | 1 Qualcomm | 58 Apq8064au, Apq8064au Firmware, Msm8996au and 55 more | 2024-04-12 | N/A | 8.2 HIGH |
| Weak configuration in Automotive while VM is processing a listener request from TEE. | |||||
| CVE-2022-22075 | 1 Qualcomm | 366 Apq8009, Apq8009 Firmware, Apq8009w and 363 more | 2024-04-12 | N/A | 5.5 MEDIUM |
| Information Disclosure in Graphics during GPU context switch. | |||||
| CVE-2022-22076 | 1 Qualcomm | 696 315 5g Iot Modem, 315 5g Iot Modem Firmware, 8953pro and 693 more | 2024-04-12 | N/A | 5.5 MEDIUM |
| information disclosure due to cryptographic issue in Core during RPMB read request. | |||||
| CVE-2023-33040 | 1 Qualcomm | 288 315 5g Iot Modem, 315 5g Iot Modem Firmware, Aqt1000 and 285 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS in Data Modem during DTLS handshake. | |||||
| CVE-2024-21390 | 1 Microsoft | 1 Authenticator | 2024-04-11 | N/A | 7.1 HIGH |
| Microsoft Authenticator Elevation of Privilege Vulnerability | |||||
| CVE-2021-46953 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 6.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ACPI: GTDT: Don't corrupt interrupt mappings on watchdow probe failure When failing the driver probe because of invalid firmware properties, the GTDT driver unmaps the interrupt that it mapped earlier. However, it never checks whether the mapping of the interrupt actially succeeded. Even more, should the firmware report an illegal interrupt number that overlaps with the GIC SGI range, this can result in an IPI being unmapped, and subsequent fireworks (as reported by Dann Frazier). Rework the driver to have a slightly saner behaviour and actually check whether the interrupt has been mapped before unmapping things. | |||||
| CVE-2021-46945 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ext4: always panic when errors=panic is specified Before commit 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()"), the following series of commands would trigger a panic: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test After commit 014c9caa29d3, remounting a file system using the test mount option "abort" will no longer trigger a panic. This commit will restore the behaviour immediately before commit 014c9caa29d3. (However, note that the Linux kernel's behavior has not been consistent; some previous kernel versions, including 5.4 and 4.19 similarly did not panic after using the mount option "abort".) This also makes a change to long-standing behaviour; namely, the following series commands will now cause a panic, when previously it did not: 1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error However, this makes ext4's behaviour much more consistent, so this is a good thing. | |||||
| CVE-2021-46942 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: io_uring: fix shared sqpoll cancellation hangs [ 736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds. [ 736.982897] Call Trace: [ 736.982901] schedule+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 We call io_uring_cancel_sqpoll() one by one for each ctx either in sq_thread() itself or via task works, and it's intended to cancel all requests of a specified context. However the function uses per-task counters to track the number of inflight requests, so it counts more requests than available via currect io_uring ctx and goes to sleep for them to appear (e.g. from IRQ), that will never happen. Cancel a bit more than before, i.e. all ctxs that share sqpoll and continue to use shared counters. Don't forget that we should not remove ctx from the list before running that task_work sqpoll-cancel, otherwise the function wouldn't be able to find the context and will hang. | |||||
| CVE-2021-46941 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Do core softreset when switch mode According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ | |||||
| CVE-2021-46926 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: intel-sdw-acpi: harden detection of controller The existing code currently sets a pointer to an ACPI handle before checking that it's actually a SoundWire controller. This can lead to issues where the graph walk continues and eventually fails, but the pointer was set already. This patch changes the logic so that the information provided to the caller is set when a controller is found. | |||||
| CVE-2021-46922 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM reservation for seal/unseal The original patch 8c657a0590de ("KEYS: trusted: Reserve TPM for seal and unseal operations") was correct on the mailing list: https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ But somehow got rebased so that the tpm_try_get_ops() in tpm2_seal_trusted() got lost. This causes an imbalanced put of the TPM ops and causes oopses on TIS based hardware. This fix puts back the lost tpm_try_get_ops() | |||||
| CVE-2021-46918 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: clear MSIX permission entry on shutdown Add disabling/clearing of MSIX permission entries on device shutdown to mirror the enabling of the MSIX entries on probe. Current code left the MSIX enabled and the pasid entries still programmed at device shutdown. | |||||
| CVE-2021-46919 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix wq size store permission state WQ size can only be changed when the device is disabled. Current code allows change when device is enabled but wq is disabled. Change the check to detect device state. | |||||