🚨 CVE-2026-10021
Insufficient validation of untrusted input in USB in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: Medium)

🎖@cveNotify

🚨 CVE-2026-10022
Type Confusion in V8 in Google Chrome prior to 148.0.7778.216 allowed an attacker who convinced a user to install a malicious extension to execute arbitrary code inside a sandbox via a crafted Chrome Extension. (Chromium security severity: Medium)

🎖@cveNotify

🚨 CVE-2026-43066
In the Linux kernel, the following vulnerability has been resolved:

ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths

During code review, Joseph found that ext4_fc_replay_inode() calls
ext4_get_fc_inode_loc() to get the inode location, which holds a
reference to iloc.bh that must be released via brelse().

However, several error paths jump to the 'out' label without
releasing iloc.bh:

- ext4_handle_dirty_metadata() failure
- sync_dirty_buffer() failure
- ext4_mark_inode_used() failure
- ext4_iget() failure

Fix this by introducing an 'out_brelse' label placed just before
the existing 'out' label to ensure iloc.bh is always released.

Additionally, make ext4_fc_replay_inode() propagate errors
properly instead of always returning 0.

🎖@cveNotify

🚨 CVE-2026-43069
In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_ll: Fix firmware leak on error path

Smatch reports:

drivers/bluetooth/hci_ll.c:587 download_firmware() warn:
'fw' from request_firmware() not released on lines: 544.

In download_firmware(), if request_firmware() succeeds but the returned
firmware content is invalid (no data or zero size), the function returns
without releasing the firmware, resulting in a resource leak.

Fix this by calling release_firmware() before returning when
request_firmware() succeeded but the firmware content is invalid.

🎖@cveNotify

🚨 CVE-2026-43070
In the Linux kernel, the following vulnerability has been resolved:

bpf: Reset register ID for BPF_END value tracking

When a register undergoes a BPF_END (byte swap) operation, its scalar
value is mutated in-place. If this register previously shared a scalar ID
with another register (e.g., after an `r1 = r0` assignment), this tie must
be broken.

Currently, the verifier misses resetting `dst_reg->id` to 0 for BPF_END.
Consequently, if a conditional jump checks the swapped register, the
verifier incorrectly propagates the learned bounds to the linked register,
leading to false confidence in the linked register's value and potentially
allowing out-of-bounds memory accesses.

Fix this by explicitly resetting `dst_reg->id` to 0 in the BPF_END case
to break the scalar tie, similar to how BPF_NEG handles it via
`__mark_reg_known`.

🎖@cveNotify

🚨 CVE-2026-43071
In the Linux kernel, the following vulnerability has been resolved:

dcache: Limit the minimal number of bucket to two

There is an OOB read problem on dentry_hashtable when user sets
'dhash_entries=1':
BUG: unable to handle page fault for address: ffff888b30b774b0
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
Oops: Oops: 0000 [#1] SMP PTI
RIP: 0010:__d_lookup+0x56/0x120
Call Trace:
d_lookup.cold+0x16/0x5d
lookup_dcache+0x27/0xf0
lookup_one_qstr_excl+0x2a/0x180
start_dirop+0x55/0xa0
simple_start_creating+0x8d/0xa0
debugfs_start_creating+0x8c/0x180
debugfs_create_dir+0x1d/0x1c0
pinctrl_init+0x6d/0x140
do_one_initcall+0x6d/0x3d0
kernel_init_freeable+0x39f/0x460
kernel_init+0x2a/0x260

There will be only one bucket in dentry_hashtable when dhash_entries is
set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,
following process will access more than one buckets(which memory region
is not allocated) in dentry_hashtable:
d_lookup
b = d_hash(hash)
dentry_hashtable + ((u32)hashlen >> d_hash_shift)
// The C standard defines the behavior of right shift amounts
// exceeding the bit width of the operand as undefined. The
// result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen',
// so 'b' will point to an unallocated memory region.
hlist_bl_for_each_entry_rcu(b)
hlist_bl_first_rcu(head)
h->first // read OOB!

Fix it by limiting the minimal number of dentry_hashtable bucket to two,
so that 'd_hash_shift' won't exceeds the bit width of type u32.

🎖@cveNotify

🚨 CVE-2026-43072
In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: platform_get_irq_byname() returns an int

platform_get_irq_byname() will return a negative value if an error
happens, so it should be checked and not just passed directly into
devm_request_threaded_irq() hoping all will be ok.

🎖@cveNotify

🚨 CVE-2026-10001
Use after free in PerformanceManager in Google Chrome prior to 148.0.7778.216 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)

🎖@cveNotify

🚨 CVE-2026-10002
Use after free in PDFium in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to potentially exploit heap corruption via a crafted PDF file. (Chromium security severity: High)

🎖@cveNotify

🚨 CVE-2026-10004
Insufficient validation of untrusted input in Passwords in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: High)

🎖@cveNotify

🚨 CVE-2026-9910
Out of bounds memory access in ANGLE in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

🎖@cveNotify

🚨 CVE-2026-9927
Use after free in ANGLE in Google Chrome prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

🎖@cveNotify

🚨 CVE-2026-9928
Out of bounds read in ANGLE in Google Chrome on Windows prior to 148.0.7778.216 allowed a remote attacker to execute arbitrary code via a crafted HTML page. (Chromium security severity: High)

🎖@cveNotify

🚨 CVE-2026-23258
In the Linux kernel, the following vulnerability has been resolved:

net: liquidio: Initialize netdev pointer before queue setup

In setup_nic_devices(), the netdev is allocated using alloc_etherdev_mq().
However, the pointer to this structure is stored in oct->props[i].netdev
only after the calls to netif_set_real_num_rx_queues() and
netif_set_real_num_tx_queues().

If either of these functions fails, setup_nic_devices() returns an error
without freeing the allocated netdev. Since oct->props[i].netdev is still
NULL at this point, the cleanup function liquidio_destroy_nic_device()
will fail to find and free the netdev, resulting in a memory leak.

Fix this by initializing oct->props[i].netdev before calling the queue
setup functions. This ensures that the netdev is properly accessible for
cleanup in case of errors.

Compile tested only. Issue found using a prototype static analysis tool
and code review.

🎖@cveNotify

🚨 CVE-2026-23259
In the Linux kernel, the following vulnerability has been resolved:

io_uring/rw: free potentially allocated iovec on cache put failure

If a read/write request goes through io_req_rw_cleanup() and has an
allocated iovec attached and fails to put to the rw_cache, then it may
end up with an unaccounted iovec pointer. Have io_rw_recycle() return
whether it recycled the request or not, and use that to gauge whether to
free a potential iovec or not.

🎖@cveNotify

🚨 CVE-2026-23260
In the Linux kernel, the following vulnerability has been resolved:

regmap: maple: free entry on mas_store_gfp() failure

regcache_maple_write() allocates a new block ('entry') to merge
adjacent ranges and then stores it with mas_store_gfp().
When mas_store_gfp() fails, the new 'entry' remains allocated and
is never freed, leaking memory.

Free 'entry' on the failure path; on success continue freeing the
replaced neighbor blocks ('lower', 'upper').

🎖@cveNotify

🚨 CVE-2026-23264
In the Linux kernel, the following vulnerability has been resolved:

Revert "drm/amd: Check if ASPM is enabled from PCIe subsystem"

This reverts commit 7294863a6f01248d72b61d38478978d638641bee.

This commit was erroneously applied again after commit 0ab5d711ec74
("drm/amd: Refactor `amdgpu_aspm` to be evaluated per device")
removed it, leading to very hard to debug crashes, when used with a system with two
AMD GPUs of which only one supports ASPM.

(cherry picked from commit 97a9689300eb2b393ba5efc17c8e5db835917080)

🎖@cveNotify

🚨 CVE-2026-20994
URL redirection in Samsung Account prior to version 15.5.01.1 allows local attackers to potentially get access token.

🎖@cveNotify

🚨 CVE-2026-45321
On 2026-05-11, between approximately 19:20 and 19:26 UTC, 84 malicious versions across 42 @tanstack/* packages were published to the npm registry. The publishes were authenticated via the legitimate GitHub Actions OIDC trusted-publisher binding for TanStack/router, but the publish workflow itself was not modified. The attacker chained three known vulnerability classes — a pull_request_target "Pwn Request" misconfiguration, GitHub Actions cache poisoning across the fork↔base trust boundary, and runtime memory extraction of the OIDC token from the Actions runner process — to publish credential-stealing malware under a trusted identity. Each affected package received exactly two malicious versions, published a few minutes apart.

🎖@cveNotify

🚨 CVE-2026-22554
MediaArea MediaInfoLib Channel Splitting heap-based buffer overflow vulnerability

🎖@cveNotify

🚨 CVE-2026-41104
Deserialization of untrusted data in Microsoft Planetary Computer Pro allows an unauthorized attacker to disclose information over a network.

🎖@cveNotify