Export limit exceeded: 403614 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (403614 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-98134 | 1 Linux | 1 Linux Kernel | 2026-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: check_cond_jmp_op(): properly infer if register is null Nicholas Carlini reported a bug when verifier can incorrectly infer that a pointer is non-null. The bug occurs when two pointers are compared and one of them has a type w/o PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL flags from pointer types, when processing comparisons like `rA == rB`, if either rA or rB can't be null. The non-null property is derived based on the absence of PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only comparison between pointers of the same type makes sense, this commit extends reg_not_null(). W/o such an extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails. reg_not_null() can be extended further, but I deem that out of scope for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID checks in the check_cond_jmp_op() can be removed with migration to reg_not_null(), but that is a behavioural change, as the special case would start matching for PTR_TO_BTF_ID that is also is_trusted_reg(). I omit the behavioural change from this commit. | ||||
| CVE-2026-98135 | 1 Linux | 1 Linux Kernel | 2026-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: reject invalid sectors_per_cluster in the boot sector is_boot_sector_ntfs() checks the boot sector's sectors_per_cluster field with a range test that rejects 0x81..0xf3 but accepts 0 and other non-power-of-two counts. A zero value reaches parse_ntfs_boot_sector(): sectors_per_cluster_bits = ffs(sectors_per_cluster) - 1; ... vol->cluster_size = vol->sector_size << sectors_per_cluster_bits; ffs(0) is 0, so sectors_per_cluster_bits becomes (unsigned)-1 and the shift is undefined: UBSAN: shift-out-of-bounds in fs/ntfs/super.c:673:39 shift exponent 4294967295 is too large for 32-bit type 'int' This change rejects any non-power-of-two value, since it feeds the aforementioned shift via ffs() - 1, which only yields the correct shift for a power of two. | ||||
| CVE-2026-106427 | 2 Apple, Google | 2 Iphone Os, Chrome | 2026-10-08 | 5.4 Medium |
| Confused deputy in Mobile in Google Chrome on on iOS prior to 155.0.8059.39 allowed a remote attacker to bypass system access restrictions into a privileged page via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-106288 | 1 Google | 1 Chrome | 2026-10-08 | 5.4 Medium |
| Missing authorization in Browser in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-106259 | 1 Google | 1 Chrome | 2026-10-08 | 5.4 Medium |
| Incorrect authorization in PermissionElement in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to bypass system access restrictions via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2023-3079 | 4 Couchbase, Debian, Fedoraproject and 1 more | 4 Couchbase Server, Debian Linux, Fedora and 1 more | 2026-10-08 | 8.8 High |
| Type confusion in V8 in Google Chrome prior to 114.0.5735.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-106271 | 1 Google | 1 Chrome | 2026-10-08 | 8.1 High |
| Missing authorization in Workers in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted PDF file. (Chromium security severity: Medium) | ||||
| CVE-2026-106263 | 1 Google | 1 Chrome | 2026-10-08 | 6.5 Medium |
| Improper input validation in SignIn in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted Chrome extension. (Chromium security severity: Medium) | ||||
| CVE-2026-106284 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-10-08 | 4.7 Medium |
| Out of bounds read in Printing in Google Chrome on on Windows prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106273 | 1 Google | 1 Chrome | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in Video in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-106275 | 1 Google | 2 Android, Chrome | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-106274 | 2 Apple, Google | 2 Macos, Chrome | 2026-10-08 | 8.8 High |
| Incorrect reference resolution in Browser in Google Chrome on on Mac prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106258 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in ANGLE in Google Chrome on on Windows prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-106272 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-10-08 | 5.4 Medium |
| UI misrepresentation in Chromoting in Google Chrome on on Windows prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to potentially spoof UI elements via crafted network traffic. (Chromium security severity: Low) | ||||
| CVE-2026-62171 | 2026-10-08 | N/A | ||
| This CVE is a duplicate of another CVE. | ||||
| CVE-2026-64002 | 1 Linux | 1 Linux Kernel | 2026-10-08 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ipv4: free net->ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table() ipv4_sysctl_exit_net() is currently freeing net->ipv4.sysctl_local_reserved_ports too soon. Only after unregister_net_sysctl_table() we can be sure no threads can possibly use the sysctls, including /proc/sys/net/ipv4/ip_local_reserved_ports. | ||||
| CVE-2026-62170 | 2026-10-08 | N/A | ||
| This CVE is a duplicate of another CVE. | ||||
| CVE-2026-98136 | 1 Linux | 1 Linux Kernel | 2026-10-08 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: bound $AttrDef table walk to the loaded table size ntfs_attr_find_in_attrdef() walks the in-memory $AttrDef table, but the loop condition bounds only the start of each entry, not the whole entry: for (ad = vol->attrdef; (u8 *)ad - (u8 *)vol->attrdef < vol->attrdef_size && ad->type; ++ad) struct attr_def is 160 bytes; the guard reads ad->type at offset 128 and the loop body reads further fields. vol->attrdef is kvzalloc(i_size), where i_size is the on-disk $AttrDef data size, checked in load_and_init_attrdef() only as 0 < i_size <= 0x7fffffff. A volume whose $AttrDef data size is smaller than one entry (e.g. 120 bytes) makes the read of ad->type run past the allocation. Creating a file reaches this through ntfs_attr_size_bounds_check() and reads out of bounds: BUG: KASAN: slab-out-of-bounds in ntfs_attr_find_in_attrdef+0x66/0xa0 Read of size 4 at addr ffff888005833280 by task init/1 ntfs_attr_find_in_attrdef ntfs_attr_size_bounds_check ntfs_attr_can_be_non_resident ntfs_attr_add Require the whole entry to lie within attrdef_size in the loop guard, and reject at mount a $AttrDef too small to hold one attr_def entry. | ||||
| CVE-2026-98137 | 1 Linux | 1 Linux Kernel | 2026-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: treat any nonzero dio zero-range return as an error ntfs_dio_zero_range() returns either 0 or a negative errno from blkdev_issue_zeroout(); it never returns a positive value. The zeroing failure check in ntfs_attr_fallocate() therefore never fired, so a failed zeroing operation was silently ignored: the loop kept going, the newly allocated clusters were folded into initialized_size and the write could succeed leaving stale on-disk data. Treat any nonzero return as an error and abort the allocation. | ||||
| CVE-2026-98138 | 1 Linux | 1 Linux Kernel | 2026-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: do not mark the volume clean in sync_fs when errors were recorded ntfs_put_super() and the remount-read-only path both clear the dirty bit only when NVolErrors(vol) is false. ntfs_sync_fs() clears it unconditionally, so any sync() on a volume that recorded an error marks that volume clean. A volume without this set is then seen as not needing recovery and it does not run one, so whatever went wrong is never repaired. This change skips resetting the dirty bit when there are volume errors. Reproduced on a volume whose $MFTMirr does not match $MFT, which sets the error flag while leaving the mount read-write: after a write and a sync, the on-disk volume flags read 0x0000 with this driver and 0x0001 with the guard in place. | ||||