Filtered by vendor Linux
Subscribe
Total
19344 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-11652 | 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 Extensions 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-46325 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 9.8 CRITICAL |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE The current implementation incorrectly handles memory regions (MRs) with page sizes different from the system PAGE_SIZE. The core issue is that rxe_set_page() is called with mr->page_size step increments, but the page_list stores individual struct page pointers, each representing PAGE_SIZE of memory. ib_sg_to_page() has ensured that when i>=1 either a) SG[i-1].dma_end and SG[i].dma_addr are contiguous or b) SG[i-1].dma_end and SG[i].dma_addr are mr->page_size aligned. This leads to incorrect iova-to-va conversion in scenarios: 1) page_size < PAGE_SIZE (e.g., MR: 4K, system: 64K): ibmr->iova = 0x181800 sg[0]: dma_addr=0x181800, len=0x800 sg[1]: dma_addr=0x173000, len=0x1000 Access iova = 0x181800 + 0x810 = 0x182010 Expected VA: 0x173010 (second SG, offset 0x10) Before fix: - index = (0x182010 >> 12) - (0x181800 >> 12) = 1 - page_offset = 0x182010 & 0xFFF = 0x10 - xarray[1] stores system page base 0x170000 - Resulting VA: 0x170000 + 0x10 = 0x170010 (wrong) 2) page_size > PAGE_SIZE (e.g., MR: 64K, system: 4K): ibmr->iova = 0x18f800 sg[0]: dma_addr=0x18f800, len=0x800 sg[1]: dma_addr=0x170000, len=0x1000 Access iova = 0x18f800 + 0x810 = 0x190010 Expected VA: 0x170010 (second SG, offset 0x10) Before fix: - index = (0x190010 >> 16) - (0x18f800 >> 16) = 1 - page_offset = 0x190010 & 0xFFFF = 0x10 - xarray[1] stores system page for dma_addr 0x170000 - Resulting VA: system page of 0x170000 + 0x10 = 0x170010 (wrong) Yi Zhang reported a kernel panic[1] years ago related to this defect. Solution: 1. Replace xarray with pre-allocated rxe_mr_page array for sequential indexing (all MR page indices are contiguous) 2. Each rxe_mr_page stores both struct page* and offset within the system page 3. Handle MR page_size != PAGE_SIZE relationships: - page_size > PAGE_SIZE: Split MR pages into multiple system pages - page_size <= PAGE_SIZE: Store offset within system page 4. Add boundary checks and compatibility validation This ensures correct iova-to-va conversion regardless of MR page size and system PAGE_SIZE relationship, while improving performance through array-based sequential access. Tests on 4K and 64K PAGE_SIZE hosts: - rdma-core/pytests $ ./build/bin/run_tests.py --dev eth0_rxe - blktest: $ TIMEOUT=30 QUICK_RUN=1 USE_RXE=1 NVMET_TRTYPES=rdma ./check nvme srp rnbd [1] https://lore.kernel.org/all/CAHj4cs9XRqE25jyVw9rj9YugffLn5+f=1znaBEnu1usLOciD+g@mail.gmail.com/T/ | |||||
| CVE-2026-46324 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: use list_del_rcu for netlink hooks nft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks need to use list_del_rcu(), this list can be walked by concurrent dumpers. Add a new helper and use it consistently. | |||||
| 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-11667 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 7.5 HIGH |
| Out of bounds read in WebRTC in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the GPU process to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-46309 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 7.0 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise Add validation in xe_vm_madvise_ioctl() to reject PAT indices with XE_COH_NONE coherency mode when applied to CPU cached memory. Using coh_none with CPU cached buffers is a security issue. When the kernel clears pages before reallocation, the clear operation stays in CPU cache (dirty). GPU with coh_none can bypass CPU caches and read stale sensitive data directly from DRAM, potentially leaking data from previously freed pages of other processes. This aligns with the existing validation in vm_bind path (xe_vm_bind_ioctl_validate_bo). v2(Matthew brost) - Add fixes - Move one debug print to better place v3(Matthew Auld) - Should be drm/xe/uapi - More Cc v4(Shuicheng Lin) - Fix kmem leak issues by the way v5 - Remove kmem leak because it has been merged by another patch v6 - Remove the fix which is not related to current fix v7 - No change v8 - Rebase v9 - Limit the restrictions to iGPU v10 - No change (cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a) | |||||
| CVE-2026-46329 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: erofs: handle end of filesystem properly for file-backed mounts I/O requests beyond the end of the filesystem should be zeroed out, similar to loopback devices and that is what we expect. | |||||
| 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-46285 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 7.8 HIGH |
| In the Linux kernel, the following vulnerability has been resolved: mtd: docg3: fix use-after-free in docg3_release() In docg3_release(), the docg3 pointer is obtained from cascade->floors[0]->priv before the loop that calls doc_release_device() on each floor. doc_release_device() frees the docg3 struct via kfree(docg3) at line 1881. After the loop, docg3->cascade->bch dereferences the already-freed pointer. Fix this by accessing cascade->bch directly, which is equivalent since docg3->cascade points back to the same cascade struct, and is already available as a local variable. This also removes the now-unused docg3 local variable. | |||||
| CVE-2026-11684 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 3.1 LOW |
| Insufficient policy enforcement in Network in Google Chrome prior to 149.0.7827.103 allowed a remote attacker who had compromised the utility process to leak cross-origin data via a crafted HTML page. (Chromium security severity: High) | |||||
| CVE-2026-11671 | 4 Apple, Google, Linux and 1 more | 4 Macos, Chrome, Linux Kernel and 1 more | 2026-07-23 | N/A | 9.6 CRITICAL |
| Use after free in Navigation in Google Chrome 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-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-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-46278 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix segfault when updating ftrace mask Fix invalid data access by passing right data for debugfs entry. [ 171.549793] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 171.559248] Mem abort info: [ 171.562173] ESR = 0x0000000096000044 [ 171.566227] EC = 0x25: DABT (current EL), IL = 32 bits [ 171.573108] SET = 0, FnV = 0 [ 171.576448] EA = 0, S1PTW = 0 [ 171.579745] FSC = 0x04: level 0 translation fault [ 171.584760] Data abort info: [ 171.588012] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 [ 171.593734] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 171.598962] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 171.604471] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000083837000 [ 171.611358] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 171.618500] Internal error: Oops: 0000000096000044 [#1] SMP [ 171.624222] Modules linked in: powervr drm_shmem_helper drm_gpuvm... [ 171.656580] CPU: 0 UID: 0 PID: 549 Comm: bash Not tainted 7.0.0-rc2-g730b257ba723-dirty #13 PREEMPT [ 171.665773] Hardware name: BeagleBoard.org BeaglePlay (DT) [ 171.671296] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 171.678306] pc : pvr_fw_trace_mask_set+0x78/0x154 [powervr] [ 171.683959] lr : pvr_fw_trace_mask_set+0x4c/0x154 [powervr] [ 171.689593] sp : ffff8000835ebb90 [ 171.692929] x29: ffff8000835ebc00 x28: ffff000005c60f80 x27: 0000000000000000 [ 171.700130] x26: 0000000000000000 x25: ffff00000504af28 x24: 0000000000000000 [ 171.707324] x23: ffff00000504af50 x22: 0000000000000203 x21: 0000000000000000 [ 171.714518] x20: ffff000005c44a80 x19: ffff000005c457b8 x18: 0000000000000000 [ 171.721715] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaae8887580 [ 171.728908] x14: 0000000000000000 x13: 0000000000000000 x12: ffff8000835ebc30 [ 171.736095] x11: ffff00000504af2a x10: ffff00008504af29 x9 : 0fffffffffffffff [ 171.743286] x8 : ffff8000835ebbf8 x7 : 0000000000000000 x6 : 000000000000002a [ 171.750479] x5 : ffff00000504af2e x4 : 0000000000000000 x3 : 0000000000000010 [ 171.757674] x2 : 0000000000000203 x1 : 0000000000000000 x0 : ffff8000835ebba0 [ 171.764871] Call trace: [ 171.767342] pvr_fw_trace_mask_set+0x78/0x154 [powervr] (P) [ 171.772984] simple_attr_write_xsigned.isra.0+0xe0/0x19c [ 171.778341] simple_attr_write+0x18/0x24 [ 171.782296] debugfs_attr_write+0x50/0x98 [ 171.786341] full_proxy_write+0x6c/0xa8 [ 171.790208] vfs_write+0xd4/0x350 [ 171.793561] ksys_write+0x70/0x108 [ 171.796995] __arm64_sys_write+0x1c/0x28 [ 171.800952] invoke_syscall+0x48/0x10c [ 171.804740] el0_svc_common.constprop.0+0x40/0xe0 [ 171.809487] do_el0_svc+0x1c/0x28 [ 171.812834] el0_svc+0x34/0x108 [ 171.816013] el0t_64_sync_handler+0xa0/0xe4 [ 171.820237] el0t_64_sync+0x198/0x19c [ 171.823939] Code: 32000262 b90ac293 1a931056 9134e293 (b9000036) [ 171.830073] ---[ end trace 0000000000000000 ]--- | |||||
| CVE-2026-46283 | 1 Linux | 1 Linux Kernel | 2026-07-23 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: tpm: Use kfree_sensitive() to free auth session in tpm_dev_release() tpm_dev_release() uses plain kfree() to free chip->auth, which contains sensitive cryptographic material including HMAC session keys, nonces, and passphrase data (struct tpm2_auth). Every other code path that frees this structure uses kfree_sensitive() to zero the memory before releasing it: both tpm2_end_auth_session() and tpm_buf_check_hmac_response() do so. The tpm_dev_release() path is the only one that does not, leaving key material in freed slab memory until it is eventually overwritten. Use kfree_sensitive() for consistency with the rest of the driver and to ensure session keys are scrubbed during device teardown. | |||||
| 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-11663 | 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 Skia 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-11629 | 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 Ozone 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: 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. | |||||
| CVE-2026-11668 | 2 Google, Linux | 3 Chrome, Chrome Os, Linux Kernel | 2026-07-23 | N/A | 4.3 MEDIUM |
| Uninitialized Use in Codecs in Google Chrome on Linux, ChromeOS prior to 149.0.7827.103 allowed a remote attacker to leak cross-origin data via a crafted video file. (Chromium security severity: High) | |||||