Export limit exceeded: 44247 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (44247 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-41022 | 1 Linux | 1 Linux Kernel | 2026-05-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq() The "instance" variable needs to be signed for the error handling to work. | ||||
| CVE-2024-41018 | 1 Linux | 1 Linux Kernel | 2026-05-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add a check for attr_names and oatbl Added out-of-bound checking for *ane (ATTR_NAME_ENTRY). | ||||
| CVE-2026-46300 | 1 Linux | 2 Kernel, Linux Kernel | 2026-05-23 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: skbuff: preserve shared-frag marker during coalescing skb_try_coalesce() can attach paged frags from @from to @to. If @from has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same externally-owned or page-cache-backed frags, but the shared-frag marker is currently lost. That breaks the invariant relied on by later in-place writers. In particular, ESP input checks skb_has_shared_frag() before deciding whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP receive coalescing has moved shared frags into an unmarked skb, ESP can see skb_has_shared_frag() as false and decrypt in place over page-cache backed frags. Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged frags. The tailroom copy path does not need the marker because it copies bytes into @to's linear data rather than transferring frag descriptors. | ||||
| CVE-2026-9301 | 1 Omec-project | 1 Amf | 2026-05-23 | 6.3 Medium |
| A vulnerability was found in omec-project amf up to 2.1.1. This vulnerability affects unknown code of the component NGReset Message Handler. Performing a manipulation results in memory corruption. The attack is possible to be carried out remotely. The exploit has been made public and could be used. It is recommended to apply a patch to fix this issue. | ||||
| CVE-2026-9300 | 1 Omec-project | 1 Amf | 2026-05-23 | 6.3 Medium |
| A vulnerability has been found in omec-project amf up to 2.1.1. This affects an unknown part of the component NGSetupRequest Handler. Such manipulation leads to memory corruption. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. It is best practice to apply a patch to resolve this issue. | ||||
| CVE-2026-43494 | 1 Linux | 1 Linux Kernel | 2026-05-23 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: net/rds: reset op_nents when zerocopy page pin fails When iov_iter_get_pages2() fails in rds_message_zcopy_from_user(), the pinned pages are released with put_page(), and rm->data.op_mmp_znotifier is cleared. But we fail to properly clear rm->data.op_nents. Later when rds_message_purge() is called from rds_sendmsg() the cleanup loop iterates over the incorrectly non zero number of op_nents and frees them again. Fix this by properly resetting op_nents when it should be in rds_message_zcopy_from_user(). | ||||
| CVE-2026-43245 | 1 Linux | 1 Linux Kernel | 2026-05-23 | 7.5 High |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: ->d_compare() must not block ... so don't use __getname() there. Switch it (and ntfs_d_hash(), while we are at it) to kmalloc(PATH_MAX, GFP_NOWAIT). Yes, ntfs_d_hash() almost certainly can do with smaller allocations, but let ntfs folks deal with that - keep the allocation size as-is for now. Stop abusing names_cachep in ntfs, period - various uses of that thing in there have nothing to do with pathnames; just use k[mz]alloc() and be done with that. For now let's keep sizes as-in, but AFAICS none of the users actually want PATH_MAX. | ||||
| CVE-2026-31707 | 1 Linux | 1 Linux Kernel | 2026-05-23 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate response sizes in ipc_validate_msg() ipc_validate_msg() computes the expected message size for each response type by adding (or multiplying) attacker-controlled fields from the daemon response to a fixed struct size in unsigned int arithmetic. Three cases can overflow: KSMBD_EVENT_RPC_REQUEST: msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz; KSMBD_EVENT_SHARE_CONFIG_REQUEST: msg_sz = sizeof(struct ksmbd_share_config_response) + resp->payload_sz; KSMBD_EVENT_LOGIN_REQUEST_EXT: msg_sz = sizeof(struct ksmbd_login_response_ext) + resp->ngroups * sizeof(gid_t); resp->payload_sz is __u32 and resp->ngroups is __s32. Each addition can wrap in unsigned int; the multiplication by sizeof(gid_t) mixes signed and size_t, so a negative ngroups is converted to SIZE_MAX before the multiply. A wrapped value of msg_sz that happens to equal entry->msg_sz bypasses the size check on the next line, and downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz, kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust the unverified length. Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUEST paths to detect integer overflow without constraining functional payload size; userspace ksmbd-tools grows NDR responses in 4096-byte chunks for calls like NetShareEnumAll, so a hard transport cap is unworkable on the response side. For LOGIN_REQUEST_EXT, reject resp->ngroups outside the signed [0, NGROUPS_MAX] range up front and report the error from ipc_validate_msg() so it fires at the IPC boundary; with that bound the subsequent multiplication and addition stay well below UINT_MAX. The now-redundant ngroups check and pr_err in ksmbd_alloc_user() are removed. This is the response-side analogue of aab98e2dbd64 ("ksmbd: fix integer overflows on 32 bit systems"), which hardened the request side. | ||||
| CVE-2026-31613 | 1 Linux | 1 Linux Kernel | 2026-05-23 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB reads parsing symlink error response When a CREATE returns STATUS_STOPPED_ON_SYMLINK, smb2_check_message() returns success without any length validation, leaving the symlink parsers as the only defense against an untrusted server. symlink_data() walks SMB 3.1.1 error contexts with the loop test "p < end", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 0. When the server-controlled ErrorDataLength advances p to within 1-7 bytes of end, the next iteration will read past it. When the matching context is found, sym->SymLinkErrorTag is read at offset 4 from p->ErrorContextData with no check that the symlink header itself fits. smb2_parse_symlink_response() then bounds-checks the substitute name using SMB2_SYMLINK_STRUCT_SIZE as the offset of PathBuffer from iov_base. That value is computed as sizeof(smb2_err_rsp) + sizeof(smb2_symlink_err_rsp), which is correct only when ErrorContextCount == 0. With at least one error context the symlink data sits 8 bytes deeper, and each skipped non-matching context shifts it further by 8 + ALIGN(ErrorDataLength, 8). The check is too short, allowing the substitute name read to run past iov_len. The out-of-bound heap bytes are UTF-16-decoded into the symlink target and returned to userspace via readlink(2). Fix this all up by making the loops test require the full context header to fit, rejecting sym if its header runs past end, and bound the substitute name against the actual position of sym->PathBuffer rather than a fixed offset. Because sub_offs and sub_len are 16bits, the pointer math will not overflow here with the new greater-than. | ||||
| CVE-2026-9299 | 1 Omec-project | 1 Amf | 2026-05-23 | 6.3 Medium |
| A flaw has been found in omec-project amf up to 2.1.1. Affected by this issue is the function PDUSessionResourceModifyIndication of the file /go/src/amf/ngap/handler.go. This manipulation causes memory corruption. Remote exploitation of the attack is possible. The exploit has been published and may be used. Applying a patch is the recommended action to fix this issue. | ||||
| CVE-2026-9298 | 1 Omec-project | 1 Amf | 2026-05-23 | 6.3 Medium |
| A vulnerability was detected in omec-project amf up to 2.1.1. Affected by this vulnerability is an unknown functionality of the component PathSwitchRequest Handler. The manipulation results in memory corruption. The attack may be launched remotely. The exploit is now public and may be used. It is advisable to implement a patch to correct this issue. | ||||
| CVE-2026-9294 | 1 Edimax | 2 Br-6428ns, Br-6428ns Firmware | 2026-05-23 | 8.8 High |
| A vulnerability was identified in Edimax BR-6428NS 1.10. The impacted element is the function formWanTcpipSetup of the file /goform/formWanTcpipSetup of the component POST Request Handler. Such manipulation of the argument pppUserName leads to buffer overflow. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-9295 | 1 Edimax | 2 Br-6428ns, Br-6428ns Firmware | 2026-05-23 | 8.8 High |
| A security flaw has been discovered in Edimax BR-6428NS 1.10. This affects the function formWirelessTbl of the file /goform/formWirelessTbl of the component POST Request Handler. Performing a manipulation of the argument vapurl results in buffer overflow. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. | ||||
| CVE-2026-8836 | 2 Lwip, Lwip-tcpip | 2 Lwip, Lwip | 2026-05-23 | 9.8 Critical |
| A vulnerability was found in lwIP up to 2.2.1. Affected is the function snmp_parse_inbound_frame of the file src/apps/snmp/snmp_msg.c of the component snmpv3 USM Handler. Performing a manipulation of the argument msgAuthenticationParameters results in stack-based buffer overflow. The attack may be initiated remotely. The patch is named 0c957ec03054eb6c8205e9c9d1d05d90ada3898c. It is suggested to install a patch to address this issue. | ||||
| CVE-2026-41073 | 1 Bestpractical | 1 Rt | 2026-05-23 | 4.6 Medium |
| RT is an open source, enterprise-grade issue and ticket tracking system. Versions prior to 5.0.10 and 6.0.0 through 6.0.2 contain a spreadsheet (CSV/formula) injection vulnerability. User-controlled data in spreadsheet exports is not sanitized before being written to the output file, which can cause spreadsheet applications to interpret crafted values as formulas or macros when the file is opened. This issue has been fixed in versions 5.0.10 and 6.0.3. If developers are unable to upgrade immediately, they can temporarily work around this issue by avoiding opening exported RT spreadsheet files directly in spreadsheet applications when the data may contain untrusted user input. | ||||
| CVE-2026-34336 | 1 Microsoft | 25 Windows 10 1607, Windows 10 1809, Windows 10 21h2 and 22 more | 2026-05-22 | 7.8 High |
| Buffer over-read in Windows DWM Core Library allows an authorized attacker to elevate privileges locally. | ||||
| CVE-2026-37470 | 1 Clipbucket | 1 Clipbucket | 2026-05-22 | 7.3 High |
| An issue in ClipBucket v5 v.5.5.2 allows an attacker to execute arbitrary code via the Authentication interface, login page endpoint and HTTP response security headers components | ||||
| CVE-2026-46598 | 1 Golang | 1 Ssh | 2026-05-22 | 5.3 Medium |
| For certain crafted inputs, a 'ed25519.PrivateKey' was created by casting malformed wire bytes, leading to a panic when used. | ||||
| CVE-2026-41071 | 2026-05-22 | N/A | ||
| libheif is a HEIF and AVIF file format decoder and encoder. In versions 1.21.2 and prior, a crafted HEIF sequence file where the saiz box declares more samples than actually exist in the track's chunk table causes a heap-buffer-overflow (out-of-bounds read) in the SampleAuxInfoReader constructor. The SampleAuxInfoReader constructor iterates over saiz->get_num_samples() samples but doesn't validate that this count is consistent with the number of chunks in the chunks vector. When saiz declares more samples than the chunks cover, the loop increments current_chunk past chunks.size(), causing an out-of-bounds read on the chunks vector. The vulnerability is triggered during file parsing (heif_context_read_from_file) without any additional user interaction. Any application using libheif to open untrusted HEIF files is affected. This issue has been fixed in version 1.22.0. | ||||
| CVE-2026-41069 | 2026-05-22 | 6.5 Medium | ||
| libheif is a HEIF and AVIF file format decoder and encoder. In versions 1.21.2 and prior, a malformed HEIF sequence file can trigger an out-of-bounds read in core sequence parsing logic, causing DoS. A malformed file can have stco.entry_count == 0 (creating no chunks) while still passing validation because saio.entry_count == 0 matches, but with saiz.sample_count > 0 the SampleAuxInfoReader constructor still enters its loop. This leads to an out-of-bounds dereference on the empty chunks[0] in chunked mode. | ||||