Filtered by vendor Linux
Subscribe
Total
19046 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-11700 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 8.3 HIGH |
| Use after free in Tracing in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Medium) | |||||
| CVE-2026-11683 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 8.8 HIGH |
| Use after free in WebCodecs in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-11640 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 8.3 HIGH |
| Integer overflow in libyuv in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: Critical) | |||||
| CVE-2026-11681 | 2 Google, Linux | 2 Chrome, Linux Kernel | 2026-07-23 | N/A | 8.8 HIGH |
| Use after free in Ozone in Google Chrome on Linux prior to 149.0.7827.103 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-11664 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 8.8 HIGH |
| Use after free in Payments in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-11694 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 7.5 HIGH |
| Use after free in ServiceWorker in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-46286 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: leds: qcom-lpg: Check for array overflow when selecting the high resolution When selecting the high resolution values from the array, FIELD_GET() is used to pull from a 3 bit register, yet the array being indexed has only 5 values in it. Odds are the hardware is sane, but just to be safe, properly check before just overflowing and reading random data and then setting up chip values based on that. | |||||
| CVE-2026-52907 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: media: rockchip: rkcif: fix off by one bugs Change these comparisons from > vs >= to avoid accessing one element beyond the end of the arrays. While at it, use ARRAY_SIZE instead of the _MAX enum values. [fix cosmetic issues] | |||||
| CVE-2026-46281 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: vmalloc: fix buffer overflow in vrealloc_node_align() Commit 4c5d3365882d ("mm/vmalloc: allow to set node and align in vrealloc") added the ability to force a new allocation if the current pointer is on the wrong NUMA node, or if an alignment constraint is not met, even if the user is shrinking the allocation. On this path (need_realloc), the code allocates a new object of 'size' bytes and then memcpy()s 'old_size' bytes into it. If the request is to shrink the object (size < old_size), this results in an out-of-bounds write on the new buffer. Fix this by bounding the copy length by the new allocation size. | |||||
| CVE-2026-52906 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 7.7 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: 9p: fix access mode flags being ORed instead of replaced Since commit 1f3e4142c0eb ("9p: convert to the new mount API"), v9fs_apply_options() applies parsed mount flags with |= onto flags already set by v9fs_session_init(). For 9P2000.L, session_init sets V9FS_ACCESS_CLIENT as the default, so when the user mounts with "access=user", both bits end up set. Access mode checks compare against exact values, so having both bits set matches neither mode. This causes v9fs_fid_lookup() to fall through to the default switch case, using INVALID_UID (nobody/65534) instead of current_fsuid() for all fid lookups. Root is then unable to chown or perform other privileged operations. Fix by clearing the access mask before applying the user's choice. | |||||
| CVE-2026-46302 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: selinux: allow multiple opens of /sys/fs/selinux/policy Currently there can only be a single open of /sys/fs/selinux/policy at any time. This allows any process to block any other process from reading the kernel policy. The original motivation seems to have been a mix of preventing an inconsistent view of the policy size and preventing userspace from allocating kernel memory without bound, but this is arguably equally bad. Eliminate the policy_opened flag and shrink the critical section that the policy mutex is held. While we are making changes here, drop a couple of extraneous BUG_ONs. | |||||
| CVE-2026-11676 | 2 Google, Linux | 3 Chrome, Chrome Os, Linux Kernel | 2026-07-23 | N/A | 8.3 HIGH |
| Insufficient validation of untrusted input in Dawn in Google Chrome on Linux and ChromeOS prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-46298 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: pseries/papr-hvpipe: Fix race with interrupt handler While executing ->ioctl handler or ->release handler, if an interrupt fires on the same cpu, then we can enter into a deadlock. This patch fixes both these handlers to take spin_lock_irq{save|restore} versions of the lock to prevent this deadlock. | |||||
| CVE-2026-11675 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 3.1 LOW |
| Out of bounds read in Skia in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-46303 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 8.2 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: isofs: validate Rock Ridge CE continuation extent against volume size rock_continue() reads rs->cont_extent verbatim from the Rock Ridge CE record and passes it to sb_bread() without checking that the block number is within the mounted ISO 9660 volume. commit e595447e177b ("[PATCH] rock.c: handle corrupted directories") added cont_offset and cont_size rejection for the CE continuation but did not validate the extent block number itself. commit f54e18f1b831 ("isofs: Fix infinite looping over CE entries") later capped the CE chain length at RR_MAX_CE_ENTRIES = 32 but again left the block number unchecked. With a crafted ISO mounted via udisks2 (desktop optical auto-mount) or via CAP_SYS_ADMIN mount, rs->cont_extent can therefore point at an out-of-range block or at blocks belonging to an adjacent filesystem on the same block device. sb_bread() on an out-of-range block returns NULL cleanly via the block layer EIO path, so there is no memory-safety violation. For in-range reads of adjacent- filesystem data, the CE buffer is parsed as Rock Ridge records and only the text of SL sub-records reaches userspace through readlink(), which makes the info-leak channel narrow and difficult to exploit; still, rejecting the malformed CE outright matches the rejection shape already present in the same function for cont_offset and cont_size. Add an ISOFS_SB(sb)->s_nzones bounds check to rock_continue() next to the existing offset/size rejection, printing the same corrupted-directory-entry notice. | |||||
| CVE-2026-11659 | 2 Google, Linux | 2 Chrome, Linux Kernel | 2026-07-23 | N/A | 9.6 CRITICAL |
| Integer overflow in UI in Google Chrome on Linux prior to 149.0.7827.103 allowed a remote attacker to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-11660 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 8.3 HIGH |
| Insufficient validation of untrusted input in New Tab Page in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-11666 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 5.4 MEDIUM |
| Insufficient validation of untrusted input in Input in Google Chrome prior to 149.0.7827.103 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-11644 | 2 Google, Linux | 2 Chrome, Linux Kernel | 2026-07-23 | N/A | 7.5 HIGH |
| Use after free in Views in Google Chrome on Linux prior to 149.0.7827.103 allowed an attacker who convinced a user to install a malicious extension to execute arbitrary code via a crafted Chrome Extension. (Chromium security severity: Critical) | |||||
| CVE-2026-46291 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: crypto: caam - guard HMAC key hex dumps in hash_digest_key Use print_hex_dump_devel() for dumping sensitive HMAC key bytes in hash_digest_key() to avoid leaking secrets at runtime when CONFIG_DYNAMIC_DEBUG is enabled. | |||||