Total
3527 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-49754 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() Smatch Warning: net/bluetooth/mgmt_util.c:375 mgmt_mesh_add() error: __memcpy() 'mesh_tx->param' too small (48 vs 50) Analysis: 'mesh_tx->param' is array of size 48. This is the destination. u8 param[sizeof(struct mgmt_cp_mesh_send) + 29]; // 19 + 29 = 48. But in the caller 'mesh_send' we reject only when len > 50. len > (MGMT_MESH_SEND_SIZE + 31) // 19 + 31 = 50. | ||||
| CVE-2022-49058 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: cifs: potential buffer overflow in handling symlinks Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer. | ||||
| CVE-2022-49023 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix buffer overflow in elem comparison For vendor elements, the code here assumes that 5 octets are present without checking. Since the element itself is already checked to fit, we only need to check the length. | ||||
| CVE-2022-48948 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. | ||||
| CVE-2022-48938 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: CDC-NCM: avoid overflow in sanity checking A broken device may give an extreme offset like 0xFFF0 and a reasonable length for a fragment. In the sanity check as formulated now, this will create an integer overflow, defeating the sanity check. Both offset and offset + len need to be checked in such a manner that no overflow can occur. And those quantities should be unsigned. | ||||
| CVE-2022-48927 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iio: adc: tsc2046: fix memory corruption by preventing array overflow On one side we have indio_dev->num_channels includes all physical channels + timestamp channel. On other side we have an array allocated only for physical channels. So, fix memory corruption by ARRAY_SIZE() instead of num_channels variable. Note the first case is a cleanup rather than a fix as the software timestamp channel bit in active_scanmask is never set by the IIO core. | ||||
| CVE-2022-48696 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: regmap: spi: Reserve space for register address/padding Currently the max_raw_read and max_raw_write limits in regmap_spi struct do not take into account the additional size of the transmitted register address and padding. This may result in exceeding the maximum permitted SPI message size, which could cause undefined behaviour, e.g. data corruption. Fix regmap_get_spi_bus() to properly adjust the above mentioned limits by reserving space for the register address/padding as set in the regmap configuration. | ||||
| CVE-2022-48657 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: arm64: topology: fix possible overflow in amu_fie_setup() cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. Multiplying max frequency by 1000 can potentially result in overflow -- multiplying by 1000ULL instead should avoid that... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. | ||||
| CVE-2023-52868 | 2025-05-04 | 4.4 Medium | ||
| In the Linux kernel, the following vulnerability has been resolved: thermal: core: prevent potential string overflow The dev->id value comes from ida_alloc() so it's a number between zero and INT_MAX. If it's too high then these sprintf()s will overflow. | ||||
| CVE-2023-52735 | 2 Linux, Redhat | 2 Linux Kernel, Rhel Eus | 2025-05-04 | 9.1 Critical |
| In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ | ||||
| CVE-2023-52733 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: s390/decompressor: specify __decompress() buf len to avoid overflow Historically calls to __decompress() didn't specify "out_len" parameter on many architectures including s390, expecting that no writes beyond uncompressed kernel image are performed. This has changed since commit 2aa14b1ab2c4 ("zstd: import usptream v1.5.2") which includes zstd library commit 6a7ede3dfccb ("Reduce size of dctx by reutilizing dst buffer (#2751)"). Now zstd decompression code might store literal buffer in the unwritten portion of the destination buffer. Since "out_len" is not set, it is considered to be unlimited and hence free to use for optimization needs. On s390 this might corrupt initrd or ipl report which are often placed right after the decompressor buffer. Luckily the size of uncompressed kernel image is already known to the decompressor, so to avoid the problem simply specify it in the "out_len" parameter. | ||||
| CVE-2023-52614 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix buffer overflow in trans_stat_show Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG in the case where we don't have enough space to write the full transition table. Also document in the ABI that this function can return -EFBIG error. | ||||
| CVE-2023-52612 | 2 Debian, Linux | 2 Debian Linux, Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem. | ||||
| CVE-2025-22104 | 2025-05-04 | 7.1 High | ||
| In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Use kernel helpers for hex dumps Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible. Therefore, create a new ibmvnic function that loops over a buffer and calls hex_dump_to_buffer instead. This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e | ||||
| CVE-2025-21780 | 2025-05-04 | 7.8 High | ||
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table() It malicious user provides a small pptable through sysfs and then a bigger pptable, it may cause buffer overflow attack in function smu_sys_set_pp_table(). | ||||
| CVE-2021-47609 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Fix string overflow in SCPI genpd driver Without the bound checks for scpi_pd->name, it could result in the buffer overflow when copying the SCPI device name from the corresponding device tree node as the name string is set at maximum size of 30. Let us fix it by using devm_kasprintf so that the string buffer is allocated dynamically. | ||||
| CVE-2021-47485 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: IB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields Overflowing either addrlimit or bytes_togo can allow userspace to trigger a buffer overflow of kernel memory. Check for overflows in all the places doing math on user controlled buffers. | ||||
| CVE-2021-47347 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: wl1251: Fix possible buffer overflow in wl1251_cmd_scan Function wl1251_cmd_scan calls memcpy without checking the length. Harden by checking the length is within the maximum allowed size. | ||||
| CVE-2021-47172 | 1 Linux | 1 Linux Kernel | 2025-05-04 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers Channel numbering must start at 0 and then not have any holes, or it is possible to overflow the available storage. Note this bug was introduced as part of a fix to ensure we didn't rely on the ordering of child nodes. So we need to support arbitrary ordering but they all need to be there somewhere. Note I hit this when using qemu to test the rest of this series. Arguably this isn't the best fix, but it is probably the most minimal option for backporting etc. Alexandru's sign-off is here because he carried this patch in a larger set that Jonathan then applied. | ||||
| CVE-2021-47107 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2025-05-04 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix READDIR buffer overflow If a client sends a READDIR count argument that is too small (say, zero), then the buffer size calculation in the new init_dirlist helper functions results in an underflow, allowing the XDR stream functions to write beyond the actual buffer. This calculation has always been suspect. NFSD has never sanity- checked the READDIR count argument, but the old entry encoders managed the problem correctly. With the commits below, entry encoding changed, exposing the underflow to the pointer arithmetic in xdr_reserve_space(). Modern NFS clients attempt to retrieve as much data as possible for each READDIR request. Also, we have no unit tests that exercise the behavior of READDIR at the lower bound of @count values. Thus this case was missed during testing. | ||||