Filtered by vendor Redhat
Subscriptions
Total
21758 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-2855 | 3 Debian, Redhat, Wireshark | 3 Debian Linux, Enterprise Linux, Wireshark | 2025-01-15 | 5.3 Medium |
| Candump log parser crash in Wireshark 4.0.0 to 4.0.5 and 3.6.0 to 3.6.13 allows denial of service via crafted capture file | ||||
| CVE-2023-28321 | 6 Apple, Debian, Fedoraproject and 3 more | 17 Macos, Debian Linux, Fedora and 14 more | 2025-01-15 | 5.9 Medium |
| An improper certificate validation vulnerability exists in curl <v8.1.0 in the way it supports matching of wildcard patterns when listed as "Subject Alternative Name" in TLS server certificates. curl can be built to use its own name matching function for TLS rather than one provided by a TLS library. This private wildcard matching function would match IDN (International Domain Name) hosts incorrectly and could as a result accept patterns that otherwise should mismatch. IDN hostnames are converted to puny code before used for certificate checks. Puny coded names always start with `xn--` and should not be allowed to pattern match, but the wildcard check in curl could still check for `x*`, which would match even though the IDN name most likely contained nothing even resembling an `x`. | ||||
| CVE-2023-28319 | 4 Apple, Haxx, Netapp and 1 more | 13 Macos, Curl, Clustered Data Ontap and 10 more | 2025-01-15 | 7.5 High |
| A use after free vulnerability exists in curl <v8.1.0 in the way libcurl offers a feature to verify an SSH server's public key using a SHA 256 hash. When this check fails, libcurl would free the memory for the fingerprint before it returns an error message containing the (now freed) hash. This flaw risks inserting sensitive heap-based data into the error message that might be shown to users or otherwise get leaked and revealed. | ||||
| CVE-2024-42159 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-15 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed. | ||||
| CVE-2024-36920 | 1 Redhat | 2 Enterprise Linux, Rhel Eus | 2025-01-15 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Avoid memcpy field-spanning write WARNING When the "storcli2 show" command is executed for eHBA-9600, mpi3mr driver prints this WARNING message: memcpy: detected field-spanning write (size 128) of single field "bsg_reply_buf->reply_buf" at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1) WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr] The cause of the WARN is 128 bytes memcpy to the 1 byte size array "__u8 replay_buf[1]" in the struct mpi3mr_bsg_in_reply_buf. The array is intended to be a flexible length array, so the WARN is a false positive. To suppress the WARN, remove the constant number '1' from the array declaration and clarify that it has flexible length. Also, adjust the memory allocation size to match the change. | ||||
| CVE-2017-14491 | 13 Arista, Arubanetworks, Canonical and 10 more | 35 Eos, Arubaos, Ubuntu Linux and 32 more | 2025-01-14 | 9.8 Critical |
| Heap-based buffer overflow in dnsmasq before 2.78 allows remote attackers to cause a denial of service (crash) or execute arbitrary code via a crafted DNS response. | ||||
| CVE-2019-9514 | 13 Apache, Apple, Canonical and 10 more | 44 Traffic Server, Mac Os X, Swiftnio and 41 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service. The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both. | ||||
| CVE-2019-9516 | 12 Apache, Apple, Canonical and 9 more | 24 Traffic Server, Mac Os X, Swiftnio and 21 more | 2025-01-14 | 6.5 Medium |
| Some HTTP/2 implementations are vulnerable to a header leak, potentially leading to a denial of service. The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory. | ||||
| CVE-2019-9517 | 12 Apache, Apple, Canonical and 9 more | 28 Http Server, Traffic Server, Mac Os X and 25 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to unconstrained interal data buffering, potentially leading to a denial of service. The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both. | ||||
| CVE-2019-9518 | 11 Apache, Apple, Canonical and 8 more | 26 Traffic Server, Mac Os X, Swiftnio and 23 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to a flood of empty frames, potentially leading to a denial of service. The attacker sends a stream of frames with an empty payload and without the end-of-stream flag. These frames can be DATA, HEADERS, CONTINUATION and/or PUSH_PROMISE. The peer spends time processing each frame disproportionate to attack bandwidth. This can consume excess CPU. | ||||
| CVE-2017-5753 | 14 Arm, Canonical, Debian and 11 more | 396 Cortex-a12, Cortex-a12 Firmware, Cortex-a15 and 393 more | 2025-01-14 | 5.6 Medium |
| Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis. | ||||
| CVE-2019-14907 | 6 Canonical, Debian, Fedoraproject and 3 more | 10 Ubuntu Linux, Debian Linux, Fedora and 7 more | 2025-01-14 | 6.5 Medium |
| All samba versions 4.9.x before 4.9.18, 4.10.x before 4.10.12 and 4.11.x before 4.11.5 have an issue where if it is set with "log level = 3" (or above) then the string obtained from the client, after a failed character conversion, is printed. Such strings can be provided during the NTLMSSP authentication exchange. In the Samba AD DC in particular, this may cause a long-lived process(such as the RPC server) to terminate. (In the file server case, the most likely target, smbd, operates as process-per-client and so a crash there is harmless). | ||||
| CVE-2019-9511 | 12 Apache, Apple, Canonical and 9 more | 29 Traffic Server, Mac Os X, Swiftnio and 26 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation, potentially leading to a denial of service. The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both. | ||||
| CVE-2019-9513 | 12 Apache, Apple, Canonical and 9 more | 25 Traffic Server, Mac Os X, Swiftnio and 22 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to resource loops, potentially leading to a denial of service. The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU. | ||||
| CVE-2019-9515 | 12 Apache, Apple, Canonical and 9 more | 36 Traffic Server, Mac Os X, Swiftnio and 33 more | 2025-01-14 | 7.5 High |
| Some HTTP/2 implementations are vulnerable to a settings flood, potentially leading to a denial of service. The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both. | ||||
| CVE-2023-30570 | 2 Libreswan, Redhat | 7 Libreswan, Enterprise Linux, Openshift and 4 more | 2025-01-14 | 7.5 High |
| pluto in Libreswan before 4.11 allows a denial of service (responder SPI mishandling and daemon crash) via unauthenticated IKEv1 Aggressive Mode packets. The earliest affected version is 3.28. | ||||
| CVE-2021-47459 | 2 Linux, Redhat | 3 Linux Kernel, Enterprise Linux, Rhel Eus | 2025-01-14 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv It will trigger UAF for rx_kref of j1939_priv as following. cpu0 cpu1 j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...) j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... j1939_netdev_stop kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref, ...) REFCOUNT_WARN("addition on 0;...") ==================================================== refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP: 0010:refcount_warn_saturate+0x169/0x1e0 Call Trace: j1939_netdev_start+0x68b/0x920 j1939_sk_bind+0x426/0xeb0 ? security_socket_bind+0x83/0xb0 The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to protect. | ||||
| CVE-2023-52859 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-14 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: perf: hisi: Fix use-after-free when register pmu fails When we fail to register the uncore pmu, the pmu context may not been allocated. The error handing will call cpuhp_state_remove_instance() to call uncore pmu offline callback, which migrate the pmu context. Since that's liable to lead to some kind of use-after-free. Use cpuhp_state_remove_instance_nocalls() instead of cpuhp_state_remove_instance() so that the notifiers don't execute after the PMU device has been failed to register. | ||||
| CVE-2023-52777 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-14 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix gtk offload status event locking The ath11k active pdevs are protected by RCU but the gtk offload status event handling code calling ath11k_mac_get_arvif_by_vdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. | ||||
| CVE-2024-35979 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-01-14 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: raid1: fix use-after-free for original bio in raid1_write_request() r1_bio->bios[] is used to record new bios that will be issued to underlying disks, however, in raid1_write_request(), r1_bio->bios[] will set to the original bio temporarily. Meanwhile, if blocked rdev is set, free_r1bio() will be called causing that all r1_bio->bios[] to be freed: raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL for (i = 0; i < disks; i++) -> for each rdev in conf // first rdev is normal r1_bio->bios[0] = bio; -> set to original bio // second rdev is blocked if (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> original bio is freed Test scripts: mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-clean fio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \ -iodepth=128 -name=test -direct=1 echo blocked > /sys/block/md0/md/rd2/state Test result: BUG bio-264 (Not tainted): Object already free ----------------------------------------------------------------------------- Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e/0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 entry_SYSCALL_64_after_hwframe+0x6c/0x74 Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_request+0xadf/0x1150 md_handle_request+0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 Since that bios for underlying disks are not allocated yet, fix this problem by using mempool_free() directly to free the r1_bio. | ||||