Vulnerability database
Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.
7,911 results · page 20 of 159
Aug 19, 2026Tanium addressed a compression bomb vulnerability in Findings.CVE-2026-11617 · Other software · Tanium · reported by 3938794e-25f5-4123-a1ba-5cbd7f104512Low 3.1
Tanium addressed a compression bomb vulnerability in Findings.
- Product
- Findings
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 19, 2026Race condition in `check.jst` in RDK-B WebUI `rdkb-2025q4-kirkstone.04.10.26` allows a remote attacker to gain unauthorized access via concurrent authenticationCVE-2026-19506 · Other software · RDK · reported by cret@cert.orgHigh 8.1
Race condition in `check.jst` in RDK-B WebUI `rdkb-2025q4-kirkstone.04.10.26` allows a remote attacker to gain unauthorized access via concurrent authentication requests that exploit shared authentication state.
- Product
- RDK-B WebUI
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recorddeveloper.rdkcentral.comwhitehats.pwr.edu.pl
Aug 19, 2026Time-of-check Time-of-use (TOCTOU) Race Condition in ZenHive mpp allows an unauthenticated remote client to redeem one confirmed on-chain payment for multiple pCVE-2026-73829 · Other software · ZenHive · reported by 6b3ad84c-e1a6-4bf7-a703-f496b71e49dbMedium 6.3
Time-of-check Time-of-use (TOCTOU) Race Condition in ZenHive mpp allows an unauthenticated remote client to redeem one confirmed on-chain payment for multiple paid-resource accesses. The type="hash" credential path in MPP.Methods.Tempo.verify/2 guards against replay with a non-atomic check-then-mark sequence: check_hash_unused/2 reads the dedup store, an eth_getTransactionReceipt round trip verifies the payment on chain, and only then does mark_hash_used/2 write the mark. Concurrent requests carrying the same settled payment hash all pass the read before any of them writes, so each is issued a receipt. The store's atomic check_and_mark/2 primitive is available and used by the type="transaction" path, but the hash path calls plain get and put even when the configured store implements it. Exploitation requires a dedup store to be configured; the default nil store is stateless and documented as offering no replay protection at all. This issue affects mpp: from 0.2.0 before 0.6.1.
- Product
- mpp
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordcna.erlef.orggithub.com
Aug 19, 2026Dell Command Update (DCU), versions prior to 5.7.1, a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability.CVE-2026-56797 · Other software · Dell · reported by security_alert@emc.comHigh 7.3
Dell Command Update (DCU), versions prior to 5.7.1, a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges.
- Product
- Dell Command Update (DCU)
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 19, 2026Dell Command Update (DCU), versions prior to 5.7.1, contain a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability.CVE-2026-53477 · Other software · Dell · reported by security_alert@emc.comHigh 7.8
Dell Command Update (DCU), versions prior to 5.7.1, contain a Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges.
- Product
- Dell Command Update (DCU)
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 19, 2026The ELF core dump code counted the number of dumpable VM map entries, allocated a buffer for the corresponding program headers, then iterated over the map a secCVE-2026-58088 · Other software · FreeBSD · reported by secteam@freebsd.orgHigh 7.4
The ELF core dump code counted the number of dumpable VM map entries, allocated a buffer for the corresponding program headers, then iterated over the map a second time to populate them. A process sharing the address space via rfork(2) can mutate the map between the two passes, causing the second pass to write program headers past the end of the buffer. An unprivileged local user sharing an address space with a process that dumps core can trigger an out-of-bounds write on the kernel heap, potentially leading to privilege escalation.
- Product
- FreeBSD
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 19, 2026The ZFS_IOC_SET_PROP ioctl, used by zfs-set(8), incorrectly validated the calling user such that an unprivileged user is able to set metadata on a dataset indicCVE-2026-49431 · Other software · FreeBSD · reported by secteam@freebsd.orgLow 3.3
The ZFS_IOC_SET_PROP ioctl, used by zfs-set(8), incorrectly validated the calling user such that an unprivileged user is able to set metadata on a dataset indicating that the dataset has received properties from a zfs-recv(8) stream. Any local user can set the internal ZFS metadata flag "$hasrecvd" on datasets via ZFS_IOC_SET_PROP.
- Product
- FreeBSD
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 18, 2026CefSharp provides .NET bindings for the Chromium Embedded Framework for Windows Forms and Windows Presentation Foundation applications.CVE-2026-48796 · Other software · cefsharp · reported by GitHubMedium 5.3
CefSharp provides .NET bindings for the Chromium Embedded Framework for Windows Forms and Windows Presentation Foundation applications. Prior to version 148.0.90, CefSharp/SchemeHandler/FolderSchemeHandlerFactory.cs used filePath.StartsWith(rootFolder, StringComparison.OrdinalIgnoreCase) to decide whether a decoded and canonicalized request path remained inside rootFolder. That raw prefix test did not enforce a directory boundary, so a request such as ..%2fwww2/secret.txt could escape a configured www directory into a sibling www2 directory whose path shared the same string prefix. Applications that register FolderSchemeHandlerFactory for a custom scheme or an HTTP or HTTPS scheme can therefore serve local files outside the intended root when an attacker can cause the embedded browser to request the crafted URL. The issue affects both Unix-style paths such as /tmp/app/www2 and Windows paths such as C:\app\www2, and the fix appends a directory separator to the normalized root before comparison while rejecting null bytes and alternate data stream syntax. This issue is fixed in version 148.0.90.
- Product
- CefSharp
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 18, 2026Race condition in USB in Google Chrome prior to 151.0.7922.169 allowed a remote attacker who had compromised the renderer process to potentially execute arbitraCVE-2026-76044 · Computers, phones & browsers · Google · reported by chrome-cve-admin@google.comHigh 8.3
Race condition in USB in Google Chrome prior to 151.0.7922.169 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)
- Product
- Chrome
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordchromereleases.googleblog.comissues.chromium.org
Aug 18, 2026Race condition in the JavaScript Engine component.CVE-2026-74984 · Computers, phones & browsers · Mozilla · reported by security@mozilla.orgMedium 6.8
Race condition in the JavaScript Engine component. This vulnerability was fixed in Firefox 154, Firefox ESR 153.1, Thunderbird 154, and Thunderbird 153.1.
- Product
- Firefox
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordbugzilla.mozilla.orgmozilla.org
Aug 18, 2026Race condition, use-after-free in the Graphics component.CVE-2026-74973 · Computers, phones & browsers · Mozilla · reported by security@mozilla.orgMedium 4.2
Race condition, use-after-free in the Graphics component. This vulnerability was fixed in Firefox 154, Firefox ESR 115.39, Firefox ESR 140.14, Firefox ESR 153.1, Thunderbird 154, Thunderbird 140.14, and Thunderbird 153.1.
- Product
- Firefox
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordbugzilla.mozilla.orgmozilla.org
Aug 18, 2026Race condition, use-after-free in the Layout: Text and Fonts component.CVE-2026-74969 · Computers, phones & browsers · Mozilla · reported by security@mozilla.orgHigh 8.8
Race condition, use-after-free in the Layout: Text and Fonts component. This vulnerability was fixed in Firefox 154, Firefox ESR 115.39, Firefox ESR 140.14, Firefox ESR 153.1, Thunderbird 154, Thunderbird 140.14, and Thunderbird 153.1.
- Product
- Firefox
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordbugzilla.mozilla.orgmozilla.org
Aug 18, 2026Information disclosure due to incorrect boundary conditions in the Graphics: CanvasWebGL component.CVE-2026-74946 · Computers, phones & browsers · Mozilla · reported by security@mozilla.orgHigh 8.8
Information disclosure due to incorrect boundary conditions in the Graphics: CanvasWebGL component. This vulnerability was fixed in Firefox 154, Firefox ESR 115.39, Firefox ESR 140.14, Firefox ESR 153.1, Thunderbird 154, Thunderbird 140.14, and Thunderbird 153.1.
- Product
- Firefox
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordbugzilla.mozilla.orgmozilla.org
Aug 18, 2026An authenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend validate.apiCVE-2026-23934 · Other software · Zabbix · reported by security@zabbix.comMedium 5.1
An authenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend validate.api.exists action, leading to potential denial of service.
- Product
- Zabbix
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 18, 2026An unauthenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend popup.testCVE-2026-23930 · Other software · Zabbix · reported by security@zabbix.comMedium 5.3
An unauthenticated user is able to cause disproportionate CPU load on the Frontend webserver by sending specifically crafted requests to the Frontend popup.testtriggerexpr action, leading to potential denial of service.
- Product
- Zabbix
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 17, 2026Certain HP Smart Tank All-in-One printers may be potentially vulnerable to a denial of service condition that allows an unauthenticated attacker to cause the deCVE-2026-17639 · Other software · HP Inc · reported by hp-security-alert@hp.comMedium 6.9
Certain HP Smart Tank All-in-One printers may be potentially vulnerable to a denial of service condition that allows an unauthenticated attacker to cause the device to become unavailable by sending multiple concurrent HTTP requests.
- Product
- HP Smart Tank 5101 All-in-One Printer
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 17, 2026INDI (Instrument Neutral Distributed Interface) indiserver through 2.2.4.2, fixed in commit 96bbd7f, contains a stack buffer overflow vulnerability that allows CVE-2026-71979 · Other software · indilib · reported by VulnCheckHigh 8.7
INDI (Instrument Neutral Distributed Interface) indiserver through 2.2.4.2, fixed in commit 96bbd7f, contains a stack buffer overflow vulnerability that allows unauthenticated remote attackers to crash the daemon by sending malformed XML with mismatched tags whose names exceed 1024 bytes. Attackers can send a single TCP packet on port 7624 with mismatched XML tags to trigger an unbounded sprintf() write into a fixed 1024-byte stack buffer in MsgQueue.cpp, terminating the daemon and disrupting all active client and driver sessions.
- Product
- indi
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 17, 2026sqlparse is a non-validating SQL parser module for Python.CVE-2026-71491 · Other software · andialbrecht · reported by GitHubHigh 8.7
sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, group_comments in sqlparse/engine/grouping.py repeatedly rescans comment-only statements before the MAX_GROUPING_TOKENS guard, causing quadratic CPU consumption through sqlparse.parse() and sqlparse.format(sql, strip_comments=True). This issue is fixed in version 0.6.0.
- Product
- sqlparse
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 17, 2026sqlparse is a non-validating SQL parser module for Python.CVE-2026-59894 · Other software · andialbrecht · reported by GitHubMedium 6.2
sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, sqlparse/filters/output.py fails to escape existing backslashes before quotes in sqlparse.format output_format='python' and output_format='php' and the corresponding sqlformat -l modes, allowing crafted SQL to terminate the generated string and inject Python or PHP code when a downstream consumer executes or imports the generated source. This issue is fixed in version 0.6.0.
- Product
- sqlparse
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 17, 2026sqlparse is a non-validating SQL parser module for Python.CVE-2026-59893 · Other software · andialbrecht · reported by GitHubHigh 7.5
sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, SQL_REGEX in sqlparse/keywords.py and the per-position loop in sqlparse/lexer.py repeatedly scan unmatched dollar-quoted literal and multiline-comment delimiters, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split(). This issue is fixed in version 0.6.0.
- Product
- sqlparse
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 17, 2026sqlparse is a non-validating SQL parser module for Python.CVE-2026-54284 · Other software · andialbrecht · reported by GitHubHigh 8.7
sqlparse is a non-validating SQL parser module for Python. Prior to 0.6.0, TokenList construction and string conversion in sqlparse/sql.py repeatedly flatten nested token subtrees constructed by group_parenthesis and group_case, causing quadratic CPU consumption through sqlparse.parse(), sqlparse.format(), and sqlparse.split() before depth and token limits terminate processing. This issue is fixed in version 0.6.0.
- Product
- sqlparse
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: net: do not send ICMP/NDISC Redirects when peer allocation fails When inet_getpeer_v4() orCVE-2026-74550 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: net: do not send ICMP/NDISC Redirects when peer allocation fails When inet_getpeer_v4() or inet_getpeer_v6() fails to allocate a peer entry under memory pressure or tree size caps, redirect handlers previously fell back to sending un-rate-limited ICMP/NDISC Redirect messages. In IPv4, ip_rt_send_redirect() called icmp_send() directly when peer == NULL. In IPv6, ip6_forward() and ndisc_send_redirect() passed a NULL peer into inet_peer_xrlim_allow(), which returned true when peer == NULL. Because ICMP/NDISC Redirects are not part of the default global rate limit mask (sysctl_icmp_ratemask), sending redirects when peer == NULL creates an un-rate-limited ICMP packet storm. Fix this by failing closed in ip_rt_send_redirect(), ip6_forward(), and ndisc_send_redirect() when peer is NULL.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: afs: Fix UAF when sending a message In afs_make_call(), there's a race with async call recCVE-2026-74506 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: afs: Fix UAF when sending a message In afs_make_call(), there's a race with async call reception and destruction. If a call is dispatched that doesn't have call->write_iter set (used to specify the data content for FS.StoreData), then the first rxrpc_kernel_send_data() will not set MSG_MORE in the msghdr. Once rxrpc_send_data() queues the last request packet, the response could come in at any time and cause the call to be completed and put. However, afs_make_call() will look at the call again to see it ->write_iter should be handled - something it's only allowed to do if it has its own ref on the call. Whilst this is the case for synchronous calls, it isn't true for async calls such as FS.FetchData. There's also a potential UAF in afs_make_call() in the event that an asynchronous call is being sent, but the call fails in some way (e.g. it gets aborted from the server). The problem there is that afs_make_call() tries to abort a call if the rxrpc send fails, but the asynchronous notification from rxrpc may have caused the afs_call to be torn down. generic/650 plays games with randomly taking CPUs offline, an
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: uprobes: Fix NULL pointer dereference in hprobe_expire() Forking a task that has a pendingCVE-2026-74477 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: uprobes: Fix NULL pointer dereference in hprobe_expire() Forking a task that has a pending uretprobe can oops the kernel with a NULL pointer dereference in the clone() path: BUG: kernel NULL pointer dereference, address: 0000000000000018 Oops: 0002 [#1] SMP NOPTI RIP: 0010:hprobe_expire CR2: 0000000000000018 Call Trace: uprobe_copy_process copy_process kernel_clone __x64_sys_clone do_syscall_64 entry_SYSCALL_64_after_hwframe This was found on real hosts on Meta fleet. I've got the impression that this is what is happening: CPU 1 CPU 2 (traced task) ----- ------------------- hit uprobe, prepare_uretprobe(): hprobe LEASED, refcount >= 1 uprobe_unregister() put_uprobe(): refcount -> 0 fork() -> dup_utask() hprobe_expire(hprobe, true) try_get_uprobe() -> NULL get_uprobe(NULL) <-- Oops Only take the extra reference whe
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: reject DX_BIND_QUERY without a DX context vmw_cmd_dx_bind_query() unconditionaCVE-2026-74445 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: reject DX_BIND_QUERY without a DX context vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx. Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment. The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob(). All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE(). Use the same pattern here, returning -EINVAL up front before any relocation state is published.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix race condition and ordering in port unregistration A synchronizationCVE-2026-74441 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix race condition and ordering in port unregistration A synchronization issue exists during port unregistration where pending partner work items can race against workqueue destruction, leading to use-after-free conditions: cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:__queue_work+0x83/0x4a0 Call Trace: <IRQ> __cfi_delayed_work_timer_fn+0x10/0x10 run_timer_softirq+0x3b6/0xbd0 sched_clock_cpu+0xc/0x110 irq_exit_rcu+0x18d/0x330 fred_sysvec_apic_timer_interrupt+0x5e/0x80 Fix this by ensuring strict ordering and proper serialization during teardown: 1. Move ucsi_unregister_partner() to the beginning of the teardown sequence and protect it under the connector mutex lock. 2. Ensure all pending partner tasks are explicitly flushed and finished before the workqueue is destroyed. 3. Switch from mod_delayed_work() to a cancel_delayed_work() and queue_delayed_work() sequence. This guarantees that items currently marked as pending won't be scheduled an additional time, preventi
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a CVE-2026-74434 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Don't move a peeked OOB message onto the pending queue rxrpc_recvmsg_oob() takes a received oob message off recvmsg_oobq and, if a response is needed, moves it onto the pending_oobq tree. However, only the unlink from recvmsg_oobq is guarded by MSG_PEEK; the move onto pending_oobq always runs. As a result, reading a challenge with MSG_PEEK leaves the skb on recvmsg_oobq while also adding it to pending_oobq. Since struct sk_buff's rbnode shares storage with its next and prev pointers, rb_insert_color() overwrites the list linkage, and the skb, which holds a single reference, becomes reachable from both queues at once. When the socket is closed both queues are drained in turn. While draining recvmsg_oobq, __skb_unlink() follows the next and prev pointers that rbnode has overwritten and writes to a bad address. Also, as the skb holds a single reference but is freed from each queue, both the skb and the connection reference it holds are released twice. This leads to memory corruption and to a use-after-free caused by the connection refcount underflow. MSG_PEEK does not consume the message from the queue, so
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path In raid1_write_request(), eaCVE-2026-74372 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: raid1: fix nr_pending leak in REQ_ATOMIC bad-block error path In raid1_write_request(), each per-mirror loop iteration begins by incrementing rdev->nr_pending. If a REQ_ATOMIC write encounters a badblock within the requested range, the code jumps to err_handle without dropping the reference taken for the current mirror. err_handle's cleanup loop will only decrements for k < i and r1_bio->bios[k] is non-NULL. The current slot is therefore skipped, leaving its nr_pending reference leaked permanently. The reference prevents the rdev from ever being removed, since raid1_remove_conf() refuses to remove an rdev with nr_pending > 0. Fix this by calling rdev_dec_pending() before jumping to err_handle.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: kernfs: fix xattr race condition with multiple superblocks Multiple superblocks with diffeCVE-2026-74343 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: kernfs: fix xattr race condition with multiple superblocks Multiple superblocks with different namespaces can share the same kernfs_node when kernfs_test_super() finds a matching root but different namespace. This means multiple inodes from different superblocks can reference the same kernfs_node->iattr->xattrs structure. The VFS layer only holds per-inode locks during xattr operations, which is insufficient to serialize concurrent xattr modifications on the shared kernfs_node. This can lead to race conditions in simple_xattr_set() where the lookup->replace/remove sequence is not atomic with respect to operations from other superblocks. Fix this by protecting xattr operations with the existing hashed kernfs_locks->open_file_mutex[] array, which is already used to protect per-node open file data. The hashed mutex array provides scalable per-node serialization (scaled by CPU count, up to 1024 locks on 32+ CPU systems) with zero memory overhead. Changes: - Rename open_file_mutex[] to node_mutex[] to reflect dual purpose - Add kernfs_node_lock_ptr() and kernfs_node_lock() helpers - Protect simple_xattr_set() calls
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-CVE-2026-74340 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.1
In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication The firmware-controlled rsp->count field is used as the loop bound for indexing into the flexible rsp->regs[] array without validation against the message length. A count exceeding the actual data causes out-of- bounds reads from the heap-allocated message buffer. Add a check that count fits within the received message.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mCVE-2026-74320 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: fbdev: sm501fb: Fix buffer errors in OF binding code The code that gets the frame buffer mode from OF has 'use after free', 'buffer overrun' and memory leaks. info->edid_data isn't free if the probe functions fail or if pd->def_mode is set. If both the CRT and PANEL are enabled info->edid_data is used after being freed and is freed twice. The string returned by of_get_property(np, "mode", &len) is just written over either the static "640x480-16@60" or the module parameter string without any regard for the length (which is most likely longer). Use kstrump() for the OF mode and free everything before freeing 'info.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a biCVE-2026-74281 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: tipc: reject inverted service ranges from peer bindings tipc_update_nametbl() inserts a binding advertised by a peer node using the lower and upper service-range bounds taken directly from the wire, without checking that lower <= upper. The local bind path validates the ordering (tipc_uaddr_valid()), but the name-distribution path does not. A binding with lower > upper is inserted at the far end of the service-range rbtree (keyed on lower) where no lookup or withdrawal can ever match it (service_range_foreach_match() requires sr->lower <= end). The publication, its service_range node and the augmented rbtree entry are then leaked for the lifetime of the namespace, and there is no per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings. Reject inverted ranges in the network path as well. A peer node can otherwise leak unbounded binding-table memory by sending PUBLICATION items with lower > upper.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modifieCVE-2026-72491 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() an
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: flow_dissector: check device type before reading ETH_ADDRS __skb_flow_dissect() unconditioCVE-2026-72444 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: flow_dissector: check device type before reading ETH_ADDRS __skb_flow_dissect() unconditionally reads 12 bytes from eth_hdr(skb) when FLOW_DISSECTOR_KEY_ETH_ADDRS is requested. This assumes the skb has a valid Ethernet header at mac_header, which is not always the case. The problem can be triggered by: 1. Creating a TUN device in L3 mode (IFF_TUN, hard_header_len=0) 2. Attaching a multiq qdisc with a flower filter matching on eth_src 3. Sending a packet through AF_PACKET Since TUN in L3 mode has no link-layer header, mac_header points to the L3 data area. The flow dissector reads 12 bytes of uninitialized skb memory, which then propagates through fl_set_masked_key() and is used as a rhashtable lookup key in __fl_lookup(), as reported by KMSAN. Rejecting the filter in the control path (at tc filter add time) is not feasible because TC filter blocks can be shared between arbitrary devices -- a filter installed on an Ethernet device may later classify packets on a headerless device through a shared block. The device association is not fixed at filter creation time. Fix this by gating the memcpy on dev->type =
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: md/raid1: fix writes_pending and barrier reference leaks on write failures raid1_make_requCVE-2026-72440 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1
In the Linux kernel, the following vulnerability has been resolved: md/raid1: fix writes_pending and barrier reference leaks on write failures raid1_make_request() acquires a writes_pending reference with md_write_start() before calling raid1_write_request(). Several failure paths in raid1_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped. Make raid1_write_request() return a status indicating whether the write request was successfully queued. This allows raid1_make_request() to call md_write_end() when raid1_write_request() fails. Additionally, if wait_blocked_rdev() fails after wait_barrier() succeeds, the associated barrier reference is not released. Call allow_barrier() before returning from that path to keep the barrier accounting balanced.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix writes_pending leak on write request failures raid10_make_request() acquireCVE-2026-72439 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix writes_pending leak on write request failures raid10_make_request() acquires a writes_pending reference with md_write_start() before dispatching write requests. Several failure paths in raid10_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped. Make raid10_write_request() return a status indicating whether the write request was successfully queued. This allows raid10_make_request() to release the writes_pending reference with md_write_end() when a write request fails.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix writes_pending and barrier reference leaks on discard failures raid10_make_CVE-2026-72438 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: md/raid10: fix writes_pending and barrier reference leaks on discard failures raid10_make_request() acquires a writes_pending reference with md_write_start() before calling raid10_handle_discard(). Several failure paths in raid10_handle_discard() complete the bio and return without releasing the corresponding reference, causing md_write_end() to be skipped. Call md_write_end() before returning from these failure paths to keep writes_pending accounting balanced. Additionally, discard split allocation failures can occur after wait_barrier() succeeds. Those paths return without calling allow_barrier(), leaking the associated barrier reference. Release the barrier before returning from those paths.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF The teql masterCVE-2026-72390 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: Introduce slaves_lock to avoid race condition and UAF The teql master->slaves singly linked list is not protected against multiple writes. It can be mod'ed concurently from teql_master_xmit(), teql_dequeue(), teql_init() and teql_destroy() without holding any list lock or RCU protection. zdi-disclosures@trendmicro.com has demonstrated that the qdisc is freed after an RCU grace period, but teql_master_xmit() running on another CPU can still hold a stale pointer into the list, resulting in a slab-use-after-free: BUG: KASAN: slab-use-after-free in teql_master_xmit+0xf0f/0x16b0 Read of size 8 at addr ffff888013fb0440 by task poc/332 Freed 512-byte region [ffff888013fb0400, ffff888013fb0600) (kmalloc-512) The fix? Add a per-master slaves_lock spinlock that serializes all mutations of master->slaves and the NEXT_SLAVE() links in teql_destroy() and teql_qdisc_init(). teql_master_xmit() also takes the same slaves_lock around those updates. Annotate master->slaves and the per-slave ->next pointer with __rcu and use the appropriate RCU accessors everywhere they are touched: rcu_assign_pointer() on t
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: afs: Fix misplaced inc of net->cells_outstanding Fix net->cells_outstanding being incremenCVE-2026-72376 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: afs: Fix misplaced inc of net->cells_outstanding Fix net->cells_outstanding being incremented before the check for failure of idr_alloc_cyclic(), leaving the count incremented on error.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: prevent invalid cursor access for purged BOs During a page table walk for bindiCVE-2026-72358 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: prevent invalid cursor access for purged BOs During a page table walk for binding, xe_pt_stage_bind() explicitly skips initializing the xe_res_cursor for purged BOs, treating them similarly to NULL VMAs by only setting the cursor size. However, xe_pt_hugepte_possible() and xe_pt_scan_64K() did not check if the BO was purged before attempting to walk the cursor using xe_res_dma() and xe_res_next(). Because the cursor was left uninitialized for purged BOs, this falls through and triggers warnings like: WARNING: drivers/gpu/drm/xe/xe_res_cursor.h:274 at xe_res_next Fix this by explicitly checking if the BO is purged in both xe_pt_hugepte_possible() and xe_pt_scan_64K(), returning early just as we do for NULL VMAs, avoiding the invalid cursor accesses entirely. As a precaution, also zero-initialize the cursor in xe_pt_stage_bind() to ensure we don't pass garbage data into the page table walkers if we ever hit a similar edge case in the future. (cherry picked from commit 4c7b9c6ece32440e5a435a92076d049450cd2d2e)
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote cheCVE-2026-72351 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: gue: validate REMCSUM private option length GUE private flags can indicate that remote checksum offload metadata is present. The private flags field itself is accounted for by guehdr_flags_len(), but guehdr_priv_flags_len() currently returns 0 even when GUE_PFLAG_REMCSUM is set. This lets a packet with only the private flags field pass validate_gue_flags(), after which gue_remcsum() and gue_gro_remcsum() read the missing REMCSUM start/offset fields from the following bytes. Account for GUE_PLEN_REMCSUM when GUE_PFLAG_REMCSUM is present so that malformed packets are rejected during option validation.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload There is a TOCTOU race condiCVE-2026-72338 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload There is a TOCTOU race condition in flower lockless approach between sizing a flow_rule buffer and filling it. zdi-disclosures@trendmicro.com reports: The cls_flower classifier operates with TCF_PROTO_OPS_DOIT_UNLOCKED (fl_change runs without RTNL), while RTM_NEWACTION holds RTNL, so the independent locking domains make the race reachable in practice. KASAN confirms: BUG: KASAN: slab-out-of-bounds in tcf_pedit_offload_act_setup+0x81b/0x930 Write of size 4 at addr ffff888001f27520 by task poc-toctou/312 The buggy address is located 0 bytes to the right of allocated 288-byte region [ffff888001f27400, ffff888001f27520) (cache kmalloc-512) Note: The result is a heap OOB write attacker-controlled content into the adjacent slab object (requires CAP_NET_ADMIN). The fix introduces reading tcfp_nkeys under act->tcfa_lock in all places using a new tcf_pedit_nkeys_locked() which replaces the old tcf_pedit_nkeys(). Additionally we close the remaining TOCTOU window between the sizing read and the fill reads by more careful accounting. Rather than sil
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Reject invalid indirect BO handle in indirect CSD setup v3d_get_cpu_indirect_csd_CVE-2026-72327 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Reject invalid indirect BO handle in indirect CSD setup v3d_get_cpu_indirect_csd_params() looks up the indirect buffer object from a userspace-supplied handle but never checks the result. A bogus or stale handle makes drm_gem_object_lookup() return NULL, which is then stored in info->indirect and only dereferenced later when the indirect CSD job runs, turning a userspace mistake into a NULL pointer dereference in the kernel. Bail out with -ENOENT as soon as the lookup fails, so the bad handle is rejected at submission time.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between devCVE-2026-72323 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: ipv4: igmp: Fix potential UAF in igmp_gq_start_timer() A race condition exists between device teardown (inetdev_destroy) and incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free in the IGMP timer callback. During device destruction, inetdev_destroy() drops the primary reference to in_device, which can drop its refcount to 0. The actual freeing of in_device memory is deferred via RCU (using call_rcu()). Concurrently, igmp_rcv() runs under RCU read lock and obtains the in_device pointer. Because the memory is RCU-protected, CPU-0 can safely dereference in_device even if its refcount has hit 0. However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it attempts to acquire a reference using in_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the in_device memory is still scheduled to be freed after the RCU grace period (as the free callback does not check the refcount again), the device is freed while the timer is still armed. When the timer expires, it accesses the freed memory, causing a kernel panic. Fix this by using r
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device CVE-2026-72322 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Fix potential UAF in MLD delayed work A race condition exists between device teardown and incoming MLD query processing, leading to a Use-After-Free in the MLD delayed work. During device destruction, the primary reference to inet6_dev is dropped, which can drop its refcount to 0. The actual freeing of inet6_dev memory is deferred via RCU. Concurrently, the packet receive path runs under RCU read lock and obtains the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can safely dereference inet6_dev even if its refcount has hit 0. However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it attempts to acquire a reference using in6_dev_hold(). This increments the refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning. Since the inet6_dev memory is still scheduled to be freed after the RCU grace period, the device is freed while the work is still scheduled. When the work runs, it accesses the freed memory, causing a kernel panic. Fix this by using refcount_inc_not_zero() (via a new helper in6_dev_hold_safe()) to prevent acquiring a reference if the device i
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs Ignore KVM's internCVE-2026-72284 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.1
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs Ignore KVM's internal "service pending PV EOI" request if the vCPU has disabled PV EOIs since the request was made. Asserting that PV EOIs are enabled can fail if reading guest memory in pv_eoi_get_user() fails, i.e. if pv_eoi_test_and_clr_pending() bails early, *and* the vCPU also disables PV EOIs. kernel BUG at arch/x86/kvm/lapic.c:3338! Oops: invalid opcode: 0000 [#1] SMP CPU: 4 UID: 1000 PID: 890 Comm: pv_eoi_test Not tainted 7.0.0-d585aa5894d8-vm #337 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_lapic_sync_from_vapic+0x12b/0x140 [kvm] Call Trace: <TASK> kvm_arch_vcpu_ioctl_run+0x1075/0x1c30 [kvm] kvm_vcpu_ioctl+0x2d5/0x980 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb5/0xb40 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]---
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocCVE-2026-72231 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: batman-adv: tt: avoid request storms during pending request batadv_send_tt_request() allocates a tt_req_node when none exists for the destination originator node. This should prevent that a multiple TT requests are send at the same time to an originator. But if allocation of the send buffer failed, this request must be cleaned up again. But indicator for such a failure is "ret == false". But the actual implementation is checking for "ret == true". The check must be inverted to not loose the information about the TT request directly after it was attempted to be sent out. This should avoid potential request storms.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: 9p: skip nlink update in cacheless mode to fix WARN_ON v9fs_dec_count() unconditionally caCVE-2026-72170 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: 9p: skip nlink update in cacheless mode to fix WARN_ON v9fs_dec_count() unconditionally calls drop_nlink() on regular files, even when the inode's nlink is already zero. In cacheless mode the client refetches inode metadata from the server (the source of truth) on every operation, so by the time v9fs_remove() returns, the locally cached nlink may already reflect the post-unlink value: 1. Client initiates unlink, server processes it and sets nlink to 0 2. Client refetches inode metadata (nlink=0) before unlink returns 3. Client's v9fs_remove() completes successfully 4. Client calls v9fs_dec_count() which calls drop_nlink() on nlink=0 This race is easily triggered under heavy unlink workloads, such as stress-ng's unlink stressor, producing the following warning: WARNING: fs/inode.c:417 at drop_nlink+0x4c/0xc8 Call trace: drop_nlink+0x4c/0xc8 v9fs_remove+0x1e0/0x250 [9p] v9fs_vfs_unlink+0x20/0x38 [9p] vfs_unlink+0x13c/0x258 ... In cacheless mode the server is authoritative and the inode is on its way out, so locally adjusting nlink buys nothing. Skip v9fs_dec_count() entirely when neit
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: fix condition in 'nand_select_target()' 'cs' here must be in range [0:nanddeCVE-2026-72165 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: fix condition in 'nand_select_target()' 'cs' here must be in range [0:nanddev_ntargets[.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count tbnet_poll() assembles a muCVE-2026-72157 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8
In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding frame_count tbnet_poll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, hdr_size, frame_size, TBNET_RX_PAGE_SIZE - hdr_size); A packet of frame_count frames therefore ends up with frame_count - 1 fragments. tbnet_check_frame() only bounds the peer supplied frame_count to TBNET_RING_SIZE / 4 (64), which is far above MAX_SKB_FRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nr_frags past MAX_SKB_FRAGS, so skb_add_rx_frag() writes past skb_shinfo()->frags[] and corrupts memory after the shared info. Tighten the start of packet bound to MAX_SKB_FRAGS + 1 so a packet can never produce more fragments than frags[] can hold. This matches the recent skb frags overflow fixes in other receive paths, for example f0813bcd2d9d ("net: wwan: t7xx: fix potential skb->frags overflow in RX path") and 600dc40554dc ("net: usb: cdc-phonet: fix skb frags[] overflow in rx_complete(
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.
Weekly security brief
The flaws that hit local websites, every Friday.
One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.
Tell us what you're building.
A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.
Not ready to talk yet? Run the free website check and see what Google sees.