The Linux kernel project published six Linux kernel CVEs in the week of 16 to 22 August 2026. The fixes are available in current upstream stable releases, but remediation is not identical across every maintained branch: CVE-2026-74582 currently has no named fix in the 5.10, 5.15 or 6.1 records. None of the six records notes known exploitation, and no public exploit code was found for any of them at the time of writing. For each product, first confirm the running kernel version, then confirm whether the vulnerable feature is built and reachable, and finally apply the newest supported kernel or a verified vendor backport. The minimum safe upstream release per branch is 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, or mainline 7.2.
Six is a small number, and it is a return to the normal rate. Last week's 1,086 records were a backlog of older assignments that the kernel CNA published in one batch. That backlog is now cleared. The six IDs this week form a contiguous block, CVE-2026-74578 through CVE-2026-74583, and all six are freshly assigned. Low volume does not mean a quiet week. Four of these six Linux kernel CVEs are memory-safety bugs in core networking or virtualization code, one is a confidentiality bug in the kernel crypto interface, and one changes how a firewall rule behaves in hardware.
At publication time, CVE-2026-74578 carries a 7.1 CVSS vector in the Linux kernel CVE record. All six records are still marked "Received" at NVD, which means NVD has not finished analysing them, and other databases and vendors may publish additional or different scores later. Prioritise by reachability and deployment context rather than by CVSS alone.
The one action: update to the fixed version for your branch
Run uname -r and compare with the table. If your version is lower than the target, update.
raghu@techveda.org:~$ uname -r
6.6.148-lts
| Stable branch | Update to at least | Notes |
|---|---|---|
| 5.10 LTS | 5.10.265 | Newest 5.10 release. Clears five of the six. CVE-2026-74582 names no 5.10 fix. |
| 5.15 LTS | 5.15.216 | Newest 5.15 release. Clears five of the six. Same CVE-2026-74582 gap. |
| 6.1 LTS | 6.1.183 | Newest 6.1 release. Clears five of the six. Same CVE-2026-74582 gap. |
| 6.6 LTS | 6.6.152 | Newest 6.6 release. Clears all six. |
| 6.12 LTS | 6.12.104 | Newest 6.12 release. Clears all six. |
| 6.18 LTS | 6.18.45 | Newest 6.18 release. Clears all six. |
| 7.1 stable | 7.1.9 | Newest 7.1 release. Clears all six. |
| mainline | 7.2 | Released 16 August 2026. All six fixes merged. |
Branches not in the table were not named as affected this week, or their fix predates this window. All eight targets are the newest release of their branch.
If you run a vendor or BSP kernel, the version string will not compare cleanly with the table. A kernel that reports 5.10.110-rk3588 is based on 5.10.110, but the vendor may have backported individual fixes on top of it, and it will not become 5.10.265 by any upstream update you apply yourself. For those products the table tells you which fixes have to be present, not which release to install. Ask your vendor to confirm, and treat a verified vendor backport as equivalent to the upstream target.
Updating to a verified fixed kernel or vendor backport is the preferred remediation. Until that is possible, reduce exposure by disabling unused features, restricting the relevant privileges, and documenting the residual risk through your product security process.
Last week's targets were 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5 and mainline 7.2-rc1. Those clear CVE-2026-74578 but none of the other five, so a new update is needed even if you patched last week.
Mobile and automotive
CVE-2026-74578: kernel crypto interface leaks plaintext to a local user
User space reaches the kernel's cipher implementations through AF_ALG sockets. The asynchronous path in skcipher_recvmsg() passed the socket-wide initialisation vector straight into the cipher request. After the request was submitted, the socket lock was dropped while the work was still in flight. A second thread could then set a new IV on the same socket and change the IV of the running request. For counter mode and other stream ciphers this reuses the keystream. Where the race described in the record is won, an unprivileged local process can recover the plaintext of another operation running at the same time. The record does not characterise how reliably the race can be driven in practice.
The fix makes the operation synchronous. In mainline the same end state was reached by removing asynchronous I/O on sockets entirely. The gate is CONFIG_CRYPTO_USER_API_SKCIPHER. It affects 4.14 and later. Fixed in 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5 and mainline 7.2.
This is relevant where untrusted local processes can open AF_ALG skcipher sockets and share or interfere with the affected socket-use pattern. AF_ALG is only one of several Linux userspace crypto interfaces, and many products reach crypto through libraries or vendor-specific paths that are not affected. Confirm your application architecture, socket ownership model, namespace policy and kernel configuration before treating this as applicable. See the CVE record and the mainline fix commit.
CVE-2026-74582: out-of-bounds write on the raw packet send path
When a program sends through a raw packet socket, the kernel reads the device's hardware header length several times while it sizes and builds the buffer. A device reconfiguration running at the same time can change that value between reads, for example when a bonding device changes type. The kernel can then save a larger value for the reserved space and allocate the headroom from a smaller one. Moving the data pointer back by the reserved amount places it before the start of the buffer, and the following copy from user space writes outside it.
Read this record carefully before you assume the branch update covers it. It marks everything from 4.17 upward as affected, and it also names the 4.4.133, 4.9.103, 4.14.44 and 4.16.12 backport lines. But it names fixed versions only for 6.6.152, 6.12.104, 6.18.45, 7.1.9 and mainline 7.2. As the record stands today, no 5.10, 5.15 or 6.1 release can be shown to clear it. If you ship one of those three branches, track the record and ask your vendor rather than assuming 5.10.265, 5.15.216 or 6.1.183 is enough. Many automotive and mobile products still ship 5.10 or 5.15, so this applies widely.
The gate is CONFIG_PACKET. Two conditions have to hold together. Opening a raw packet socket requires CAP_NET_RAW in the relevant user namespace, and the race additionally requires a device being reconfigured at the same time, which is itself a privileged operation. DHCP clients, provisioning agents and diagnostic tools may use raw packet sockets, depending on the product architecture. See the CVE record and the mainline fix commit.
Embedded and IoT
CVE-2026-74583: use-after-free in the route4 traffic classifier
The route4 classifier keeps a small 16-slot cache of filter pointers so it can skip the full lookup for traffic it has already seen. The read side fills that cache for every packet that matches a filter. The write side clears the cache before it frees a deleted filter. The two are not ordered against each other. A reader that is already in flight can write the filter pointer back into the cache after the writer has cleared it, so the pointer stays cached while the filter is freed. The next packet with the same identifier and input interface then reads freed memory. The fix adds a per-filter flag that stops an in-flight reader from re-publishing a filter that is on its way out.
This one was confirmed with KASAN. The mainline fix credits the report to ZDI and to Santosh Kalluri. The bug has been present since 3.18, which is more than ten years. After the filter is set up, the trigger is ordinary classified traffic rather than a syscall. The gate is CONFIG_NET_CLS_ROUTE4. Using tc does not by itself mean route4 is in use — it is one classifier among many. Check whether the code is loaded and whether any rule actually uses it.
raghu@techveda.org:~$ lsmod | grep cls_route
cls_route 16384 0
raghu@techveda.org:~$ tc filter show dev eth0
filter parent 1: protocol ip pref 100 route chain 0
A zero in the third column of lsmod means the module is loaded but has no users. If tc filter show lists no route filter on any interface, the classifier is present but not in the data path. Fixed in 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 and mainline 7.2. See the CVE record and the mainline fix commit.
CVE-2026-74579: nftables offload mask can be wider than the rule
When an nftables rule matches only part of a header field and the rule is pushed down to the network card, the kernel builds a match mask for the hardware. That mask was built with a bit shift that is undefined when the field is large. For a partial IPv6 address match the shift is 120 places on a 32-bit value, which UBSAN reports as a shift out of bounds. The routine also cleared only one word of the mask, so the remaining words stayed all-ones, and when the matched length was a multiple of four it cleared nothing at all. The mask handed to the hardware therefore covered more bytes than the rule was written to match.
The consequence here is not memory corruption. It is a security control that behaves differently in hardware than in software. An over-broad mask can make an offloaded rule match traffic the administrator did not intend, or fail to match traffic they did. The practical effect depends on the NIC driver, the flow-offload implementation, the rule type in use, and whether the rule was actually accepted for offload rather than silently falling back to software. Before you assign exposure, confirm all four: CONFIG_NF_TABLES is built, flowtable or hardware offload is configured, the NIC driver supports it, and an active rule is genuinely offloaded.
Setting up the rule needs CAP_NET_ADMIN. It affects 5.10 and later, plus the 5.9.14 backport line. Fixed in 5.10.265, 5.15.216, 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8 and mainline 7.2. See the CVE record and the mainline fix commit.
Cloud and datacenter
CVE-2026-74580: vhost keeps a stale address translation after a vring is reconfigured
The vhost driver caches the IOTLB mapping behind each vring metadata region so it does not have to validate the same address twice. A cache hit is treated as proof that the region was already checked. The cache is cleared when the IOTLB is updated, invalidated or re-initialised, and when the queue is reset. It was not cleared when the guest changed the vring addresses or the vring size through the corresponding ioctls. Both of those ioctls are accepted while the queue is live, and neither validates the addresses at ioctl time, because the addresses are guest IOVAs and validation is deferred until prefetch. Once the cache is warm that deferred validation never runs again, and the driver keeps translating new addresses through the old mapping.
The result is that a descriptor fetch or a used-ring update on the host can read or write host memory outside the region the IOTLB actually maps. This is the guest-to-host surface of the week. On a host running untrusted guests it belongs at the top of the list, ahead of the local-only issues. Before assigning exposure, confirm all four conditions: CONFIG_VHOST is built or loadable, a relevant vhost backend is active, a device-IOTLB path is attached, and the host permits the guest-driven vring reconfiguration the record describes.
It affects 4.11 and later. Fixed in 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 and mainline 7.2. See the CVE record and the mainline fix commit.
CVE-2026-74581: IPv6 policy routing can return a released route
An IPv6 routing rule can be configured to suppress a result, so that the lookup falls through to the next rule. The suppression code released the route but left the rule result still pointing at it. If no later rule supplied a replacement, the lookup returned that released route to its caller. The next release of that route then operated on freed memory. The fix clears the result when the route is suppressed.
Suppressing rules are common in container networking, VPN setups and any product that uses policy routing to steer traffic between tables. The gate is CONFIG_IPV6_MULTIPLE_TABLES, which links the rule code into the ipv6 module rather than building a module of its own, so it also needs CONFIG_IPV6. It affects 5.16 and later, and also the 5.10.84, 5.15.7 and 5.4.164 backport lines. Fixed in 5.10.265, 5.15.216, 6.1.183, 6.6.151, 6.12.103, 6.18.44, 7.1.8 and mainline 7.2. See the CVE record and the mainline fix commit.
Medical devices
Several of this week's bugs are worth reviewing for connected clinical equipment. They fall into three groups.
-
Network stack. A device that carries DICOM, HL7 or FHIR over IP and uses IPv6 policy routing should review
CVE-2026-74581. A device whose network provisioning or diagnostic agent opens a raw packet socket should reviewCVE-2026-74582, and note that the record names no fix for 5.10, 5.15 or 6.1. -
Cryptography. A device that encrypts patient data or a session key through the kernel's AF_ALG interface should review
CVE-2026-74578. It is the highest-scored CVE this week and an unprivileged local process is enough to reach it. -
Gateways and carts. An imaging cart, a bedside gateway or a ward router built on Linux may enable traffic shaping or nftables hardware offload, in which case
CVE-2026-74583andCVE-2026-74579apply as they do to any other gateway.
Patching a medical device is not the same as patching a server. The update has to pass validation and regulatory revalidation. The rules that apply are the US FDA postmarket cybersecurity guidance, the EU Medical Device Regulation (MDR) and IEC 62304. So the action is to plan the stable kernel update through the manufacturer's change-control process.
How to check which Linux kernel CVEs apply to you
First, version. Run uname -r and compare with the table. On 6.6, 6.12, 6.18, 7.1 and mainline that clears the whole set. On 5.10, 5.15 and 6.1 it clears five of the six, and CVE-2026-74582 has to be tracked separately.
Second, configuration. If the vulnerable code is not built into the kernel or available as a loadable module, the CVE is generally not reachable through that feature. Confirm dependencies, module-loading policy and vendor configuration before you close the finding.
raghu@techveda.org:~$ zcat /proc/config.gz | grep -E '^(# )?CONFIG_(PACKET|CRYPTO_USER_API_SKCIPHER|NET_CLS_ROUTE4|NF_TABLES|VHOST|IPV6_MULTIPLE_TABLES)[ =]'
CONFIG_PACKET=y
CONFIG_CRYPTO_USER_API_SKCIPHER=m
# CONFIG_NET_CLS_ROUTE4 is not set
CONFIG_NF_TABLES=m
# CONFIG_VHOST is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
The pattern is anchored on purpose. A plain grep CONFIG_VHOST would also match every CONFIG_VHOST_* sub-option. Read =m differently from =y: a symbol set to m means the code is present and can be loaded, so it still counts as reachable unless your module-loading policy prevents it.
Third, reachability. None of the six records describes an unauthenticated remote party supplying the input, so the top of the list is local unprivileged access rather than an over-the-air bug. The records describe code paths, not attacker models, so the ordering below is a reading of reachability and not a statement from the kernel CVE team.
On a host that runs untrusted guests, CVE-2026-74580 comes first, because it crosses the guest-to-host boundary. Everywhere else, CVE-2026-74578 comes first, then CVE-2026-74582, then CVE-2026-74581 and CVE-2026-74583, then CVE-2026-74579.
Key takeaways
- Update to the target release for your branch: 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9, or mainline 7.2. On a vendor or BSP kernel, ask the vendor to confirm the fixes are in their tree rather than comparing version strings.
- Six CVEs is a low count, but the set is not routine. Four are memory-safety bugs in core networking or virtualization code.
- CVE-2026-74582 is the exception the branch update does not cover on 5.10, 5.15 and 6.1. Track it separately.
- Schedule CVE-2026-74578 first, except on hosts running untrusted guests, where CVE-2026-74580 comes first.
- Five other CVE IDs were rejected in this window and are no longer valid records: CVE-2026-74511, CVE-2026-64158, CVE-2026-72044, CVE-2026-72246 and CVE-2026-68101.
- None of the six records notes known exploitation, and no public exploit code was found at the time of writing. That is a point-in-time check, not a guarantee.
Top comments (0)