Linux Kernel CVEs: What to Patch by Device (16 – 22 Aug 2026)

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. There is no filler in this set.

Most kernel fixes are narrow. Which ones matter for you depends on what your product builds and how it is configured. 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. This advisory gives the version to install first, then explains which CVEs matter for mobile and automotive, embedded and IoT, cloud and datacenter, and medical devices. Each CVE below has its own heading so you can link straight to it.

The one action: update to the fixed version for your branch

Run uname -r to see your current kernel version. Compare it with the target for your branch in the table below. If your version is lower than the target, update to the target release or newer.

raghu@techveda.org:~$ uname -r
6.6.148-lts

In that example the running kernel is 6.6.148, which is below the 6.6 target of 6.6.152, so the system needs an update.

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 silicon or BSP vendor to confirm the fix is in their tree, 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.

Branches not in the table were not named as affected by any record this week, or their fix was released before this window. The 6.19 and 7.0 series no longer appear on the kernel.org active release list, and no record this week names them. Every target above is a release that already exists, so nothing here waits on a future stable release. In fact all eight targets are the newest release of their branch, which makes this week simple: install the current release for your branch.

One comparison is worth making. 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, because that CVE’s fixed versions are exactly last week’s targets. They do not clear the other five. So if you applied last week’s advisory, you still need this week’s update.

Mobile and automotive

Two bugs this week are reachable by ordinary application code on a device that runs software from several suppliers side by side. That is the normal situation on a phone, a tablet and a car head unit.

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.

At publication time this record carries a 7.1 CVSS vector, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. It is the kernel CNA’s own score, carried as a secondary metric. NVD has not finished analysing the record and publishes no base score of its own, and other vendors and enrichment databases may publish different figures. The fix makes the operation synchronous, so the race cannot happen. 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, which is a realistic situation on a device running code from several vendors under different unprivileged users. 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 on head units and phones may use raw packet sockets, depending on the product architecture. See the CVE record and the mainline fix commit.

Embedded and IoT

Two bugs sit in networking features that routers, gateways and industrial controllers commonly enable.

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. Gateways, routers and industrial controllers that do traffic shaping or QoS with tc are the systems most likely to build it, but 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 fix sets the first matched bytes directly and removes the shift.

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. That is worth checking on any gateway or industrial firewall that offloads nftables rules to the NIC. 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. The gate is CONFIG_NF_TABLES together with hardware traffic-control offload on the interface, and 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

One guest-to-host bug and one routing bug matter most on shared and multi-tenant hosts.

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, because the boundary it crosses is the one that matters most in that setting. 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. The gate is CONFIG_VHOST, reached in practice through CONFIG_VHOST_NET or CONFIG_VHOST_VDPA with a device IOTLB attached. 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, so a suppressed lookup falls through to the null route instead of reusing the released one.

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 review CVE-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-74583 and CVE-2026-74579 apply 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. Do not apply it outside that process.

How to check which Linux kernel CVEs apply to you

There are three questions.

First, version. Run uname -r and compare the result with the table above. If your release is below the target for your branch, update to the target or newer. 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. Check your kernel config for the feature behind each CVE. 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. On a running system with config access enabled, one command covers this week’s whole set.

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, which buries the answer.

In that output, the route4 classifier and vhost bugs can be set aside, because the code is not built at all. Read =m differently from =y: a symbol set to m means the code is present on the system and can be loaded, so it still counts as reachable unless your module-loading policy prevents it. If your system has no /proc/config.gz, use the config file from your build tree or the matching file under /boot.

Third, reachability, which sets the order of work. 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. Note that the records describe the code paths, not attacker models, so the ordering below is our reading of reachability and not a statement from the kernel CVE team. The order also depends on what your host does, so take the following as two cases rather than one list.

On a host that runs untrusted guests, CVE-2026-74580 comes first. It crosses the guest-to-host boundary, which in a multi-tenant setting is a more serious boundary than any local one, and it should be scheduled ahead of the local issues below rather than after them.

Everywhere else, CVE-2026-74578 comes first: it needs no capability beyond opening an AF_ALG socket, and the result is another process’s plaintext. CVE-2026-74582 comes next, because it is an out-of-bounds write, though it needs CAP_NET_RAW plus a concurrent reconfiguration. CVE-2026-74581 and CVE-2026-74583 need a specific routing or traffic-control configuration to be in place and active. CVE-2026-74579 comes last, because it needs CAP_NET_ADMIN and a rule genuinely offloaded to hardware, and its effect is a wrong rule rather than memory corruption.

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. All eight are the newest release of their branch, so on an upstream kernel the action is simply to install the current release. 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. The record marks those branches affected and names no fix for them. Track it separately.
• Schedule CVE-2026-74578 first. It is the only CVE this week carrying a CVSS score, 7.1 HIGH from the kernel CNA rather than from NVD, and an unprivileged local process that wins the race can recover another process’s plaintext.
• On a host running untrusted guests, put the guest-to-host fix CVE-2026-74580 ahead of the local issues, not after them. Confirm the backend, the device-IOTLB path and the reconfiguration scenario before assigning exposure.
• Last week’s targets clear CVE-2026-74578 but none of the other five, so a new update is needed even if you patched last week.
• Five other CVE IDs were rejected in this window and are no longer valid records. If your scanner still reports CVE-2026-74511, CVE-2026-64158, CVE-2026-72044, CVE-2026-72246 or CVE-2026-68101, they can be dropped.
• None of the six records notes known exploitation, and no public exploit code was found for any of them at the time of writing. That is a point-in-time check, not a guarantee. Use your kernel config to remove the CVEs that do not apply, then test the update on your own hardware.

Frequently asked questions

What is the one thing I should do?
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. If you run a vendor or BSP kernel, ask your vendor to confirm the fixes are in their tree instead, because a vendor version string will not compare cleanly with those numbers. Then use your kernel config and device type to decide what to test first.

Only six CVEs. Is this a quiet week?
The count is low, but the set is not routine. Four of the six are memory-safety bugs in core networking or virtualization code, one is a confidentiality bug in the kernel crypto interface, and one changes how an offloaded firewall rule behaves. Last week’s 1,086 records were a backlog of older assignments published in one batch, so six is a return to the normal rate.

Are any of these a 0-day?
No. All six were published with fixes already in stable. None of the records notes known exploitation, and no public exploit code was found for any of them at the time of writing, though that is a point-in-time check rather than a guarantee. The action is to schedule the stable update through your normal process.

I run 5.10, 5.15 or 6.1. Am I covered?
Not fully. Those branches clear five of the six CVEs at 5.10.265, 5.15.216 and 6.1.183. CVE-2026-74582 marks everything from 4.17 upward as affected but 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. Track the record and ask your vendor.

Which one should I schedule first?
CVE-2026-74578 in the kernel crypto interface. It is the only CVE this week carrying a CVSS score, 7.1 HIGH, and an unprivileged local process that wins the race can recover another process’s plaintext. Note that the score comes from the kernel CNA and not from an NVD analyst, because NVD has not finished analysing these records. CVE-2026-74582 comes next, because it is an out-of-bounds write on the raw packet send path.

I already applied last week’s targets. Do I need to update again?
Yes. 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. Update to this week’s targets.

We do not build packet sockets, nftables or vhost. Do these affect us?
Each bug is gated by a kernel config option: CONFIG_PACKET, CONFIG_CRYPTO_USER_API_SKCIPHER, CONFIG_NET_CLS_ROUTE4, CONFIG_NF_TABLES, CONFIG_VHOST and CONFIG_IPV6_MULTIPLE_TABLES. 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. Read a symbol set to m as still present and loadable rather than absent, and confirm dependencies, module-loading policy and vendor configuration before you close the finding.

Further reading

• linux-cve-announce, 16 to 22 August 2026
• CVE-2026-74578 (kernel crypto interface) and CVE-2026-74582 (raw packet send path)
• CVE-2026-74583 (route4 classifier) and CVE-2026-74579 (nftables offload mask)
• CVE-2026-74580 (vhost, guest to host) and CVE-2026-74581 (IPv6 policy routing)
• kernel.org active releases and projected end-of-life dates
• Previous edition: Linux Kernel CVEs, 9 to 15 August 2026