Total
3510 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2021-46912 | 1 Linux | 1 Linux Kernel | 2024-04-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net: Make tcp_allowed_congestion_control readonly in non-init netns Currently, tcp_allowed_congestion_control is global and writable; writing to it in any net namespace will leak into all other net namespaces. tcp_available_congestion_control and tcp_allowed_congestion_control are the only sysctls in ipv4_net_table (the per-netns sysctl table) with a NULL data pointer; their handlers (proc_tcp_available_congestion_control and proc_allowed_congestion_control) have no other way of referencing a struct net. Thus, they operate globally. Because ipv4_net_table does not use designated initializers, there is no easy way to fix up this one "bad" table entry. However, the data pointer updating logic shouldn't be applied to NULL pointers anyway, so we instead force these entries to be read-only. These sysctls used to exist in ipv4_table (init-net only), but they were moved to the per-net ipv4_net_table, presumably without realizing that tcp_allowed_congestion_control was writable and thus introduced a leak. Because the intent of that commit was only to know (i.e. read) "which congestion algorithms are available or allowed", this read-only solution should be sufficient. The logic added in recent commit 31c4d2f160eb: ("net: Ensure net namespace isolation of sysctls") does not and cannot check for NULL data pointers, because other table entries (e.g. /proc/sys/net/netfilter/nf_log/) have .data=NULL but use other methods (.extra2) to access the struct net. | |||||
| CVE-2023-33056 | 1 Qualcomm | 232 Ar8035, Ar8035 Firmware, Csr8811 and 229 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS in WLAN Firmware when firmware receives beacon including T2LM IE. | |||||
| CVE-2022-33294 | 1 Qualcomm | 24 Mdm8207, Mdm8207 Firmware, Mdm9205 and 21 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS in Modem due to NULL pointer dereference while receiving response of lwm2m registration/update/bootstrap request message. | |||||
| CVE-2022-33305 | 1 Qualcomm | 162 315 5g Iot Modem, 315 5g Iot Modem Firmware, Ar8035 and 159 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS due to NULL pointer dereference in Modem while sending invalid messages in DCCH. | |||||
| CVE-2022-33223 | 1 Qualcomm | 24 Mdm8207, Mdm8207 Firmware, Mdm9205 and 21 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS in Modem due to null pointer dereference while processing the incoming packet with http chunked encoding. | |||||
| CVE-2022-33304 | 1 Qualcomm | 80 9205 Lte Modem, 9205 Lte Modem Firmware, 9206 Lte Modem and 77 more | 2024-04-12 | N/A | 7.5 HIGH |
| Transient DOS due to NULL pointer dereference in Modem while performing pullup for received TCP/UDP packet. | |||||
| CVE-2022-25733 | 1 Qualcomm | 70 Ar8031, Ar8031 Firmware, Csra6620 and 67 more | 2024-04-12 | N/A | 7.5 HIGH |
| Denial of service in modem due to null pointer dereference while processing DNS packets | |||||
| CVE-2022-25735 | 1 Qualcomm | 68 Ar8031, Ar8031 Firmware, Csra6620 and 65 more | 2024-04-12 | N/A | 7.5 HIGH |
| Denial of service in modem due to missing null check while processing TCP or UDP packets from server | |||||
| CVE-2022-25739 | 1 Qualcomm | 52 Mdm8207, Mdm8207 Firmware, Mdm9205 and 49 more | 2024-04-12 | N/A | 7.5 HIGH |
| Denial of service in modem due to missing null check while processing the ipv6 packet received during ECM call | |||||
| CVE-2023-33036 | 1 Qualcomm | 208 Aqt1000, Aqt1000 Firmware, Ar8035 and 205 more | 2024-04-12 | N/A | 5.5 MEDIUM |
| Permanent DOS in Hypervisor while untrusted VM without PSCI support makes a PSCI call. | |||||
| CVE-2021-46949 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX flush done handling We're starting from a TXQ instance number ('qid'), not a TXQ type, so efx_get_tx_queue() is inappropriate (and could return NULL, leading to panics). | |||||
| CVE-2021-46948 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX event handling We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return NULL, leading to panics). | |||||
| CVE-2021-46947 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues efx->xdp_tx_queue_count is initially initialized to num_possible_cpus() and is later used to allocate and traverse efx->xdp_tx_queues lookup array. However, we may end up not initializing all the array slots with real queues during probing. This results, for example, in a NULL pointer dereference, when running "# ethtool -S <iface>", similar to below [2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [2570283.681283][T4126959] #PF: supervisor read access in kernel mode [2570283.695678][T4126959] #PF: error_code(0x0000) - not-present page [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Hardware name: <redacted> [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202 [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0 [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Call Trace: [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830 Fix this by adjusting efx->xdp_tx_queue_count after probing to reflect the true value of initialized slots in efx->xdp_tx_queues. | |||||
| CVE-2021-46916 | 1 Linux | 1 Linux Kernel | 2024-04-10 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: ixgbe: Fix NULL pointer dereference in ethtool loopback test The ixgbe driver currently generates a NULL pointer dereference when performing the ethtool loopback test. This is due to the fact that there isn't a q_vector associated with the test ring when it is setup as interrupts are not normally added to the test rings. To address this I have added code that will check for a q_vector before returning a napi_id value. If a q_vector is not present it will return a value of 0. | |||||
| CVE-2018-14553 | 5 Canonical, Debian, Fedoraproject and 2 more | 5 Ubuntu Linux, Debian Linux, Fedora and 2 more | 2024-04-07 | 4.3 MEDIUM | 7.5 HIGH |
| gdImageClone in gd.c in libgd 2.1.0-rc2 through 2.2.5 has a NULL pointer dereference allowing attackers to crash an application via a specific function call sequence. Only affects PHP when linked with an external libgd (not bundled). | |||||
| CVE-2024-31420 | 2024-04-03 | N/A | N/A | ||
| A NULL pointer dereference flaw was found in KubeVirt. This flaw allows an attacker who has access to a virtual machine guest on a node with DownwardMetrics enabled to cause a denial of service by issuing a high number of calls to vm-dump-metrics --virtio and then deleting the virtual machine. | |||||
| CVE-2020-10703 | 1 Redhat | 1 Libvirt | 2024-04-01 | 4.0 MEDIUM | 6.5 MEDIUM |
| A NULL pointer dereference was found in the libvirt API responsible introduced in upstream version 3.10.0, and fixed in libvirt 6.0.0, for fetching a storage pool based on its target path. In more detail, this flaw affects storage pools created without a target path such as network-based pools like gluster and RBD. Unprivileged users with a read-only connection could abuse this flaw to crash the libvirt daemon, resulting in a potential denial of service. | |||||
| CVE-2022-36227 | 4 Debian, Fedoraproject, Libarchive and 1 more | 4 Debian Linux, Fedora, Libarchive and 1 more | 2024-03-27 | N/A | 9.8 CRITICAL |
| In libarchive before 3.6.2, the software does not check for an error after calling calloc function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference. NOTE: the discoverer cites this CWE-476 remark but third parties dispute the code-execution impact: "In rare circumstances, when NULL is equivalent to the 0x0 memory address and privileged code can access it, then writing or reading memory is possible, which may lead to code execution." | |||||
| CVE-2022-23222 | 4 Debian, Fedoraproject, Linux and 1 more | 19 Debian Linux, Fedora, Linux Kernel and 16 more | 2024-03-25 | 7.2 HIGH | 7.8 HIGH |
| kernel/bpf/verifier.c in the Linux kernel through 5.15.14 allows local users to gain privileges because of the availability of pointer arithmetic via certain *_OR_NULL pointer types. | |||||
| CVE-2023-31083 | 1 Linux | 1 Linux Kernel | 2024-03-25 | N/A | 4.7 MEDIUM |
| An issue was discovered in drivers/bluetooth/hci_ldisc.c in the Linux kernel 6.2. In hci_uart_tty_ioctl, there is a race condition between HCIUARTSETPROTO and HCIUARTGETPROTO. HCI_UART_PROTO_SET is set before hu->proto is set. A NULL pointer dereference may occur. | |||||