Linux Kernel CVEs: What to Patch by Device (1 – 7 Nov 2026)

This week has 61 live Linux kernel CVEs. Most fixes are narrow, so which ones matter depends on what your product uses. The records were published on four days: 26 on 2 Nov, 28 on 3 Nov, 3 on 6 Nov, 14 on 7 Nov. Nothing was published on 1, 4 or 5 November. Most of the volume is in tracing, keys, io_uring and the SMB code. This post describes 17 of the 61 live records in detail and names more. The full list with files and fixed versions is in the weekly report.

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

Run uname -r and find your branch in the table. If your version is lower than the value in the second column, plan the update. Each value is the highest fixed version named by any live record this week for that branch. Every value equals the newest release in the kernel.org release list on 8 November 2026, so a later update does not need a higher number for these records.

raghu@techveda.org:~$ uname -r
6.12.114

The output above is an example. 6.12.114 is below 6.12.116, so that system needs the update.

Branches that are not listed were not affected, or the fix was released before this window. Many records list a fix only for newer branches. This week 46 of the 61 live records list no fix for 5.10, and 34 list none for 6.1. The record does not say whether the older code is exposed, so check your tree. For example CVE-2026-99270 lists a stable fix only for 6.18.61 and mainline 7.1, and CVE-2026-99272 lists fixes only for 7.3.2.

Mobile and automotive

Phones, cars and wearables use Bluetooth, the TCP/IP stack and vendor system-on-chip (SoC) drivers. The records below apply to those parts.

CVE-2026-99239: Bluetooth L2CAP channel linked to a connection twice

A channel must be linked to one connection at most. The record shows a race: one task calls l2cap_chan_connect while another calls l2cap_sock_bind on the same channel. The second connect() then adds the channel to a connection again. The fix adds a check in __l2cap_chan_add and a lock in l2cap_sock_bind(). The CNA scores it 7.8 HIGH with a local vector, so the reach is a local process that uses Bluetooth sockets, not a radio frame. The source file net/bluetooth/l2cap_core.c is built only on kernels with Bluetooth. The record lists affected stable ranges that start at 5.10.265, 5.15.216, 6.1.183, 6.6.145, 6.12.97 and 6.18.39. Fixes are in every branch of the table: 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.60, 7.2.14 and 7.3.1. See the cve.org record.

CVE-2026-99259: Tegra PMC suspend warning on 32-bit devices

On legacy 32-bit Tegra devices, tegra_pmc_enter_suspend_mode() warns because early_pmc->rate is never set and stays 0. The cause is a change that creates the PMC context dynamically and sets the rate only in the new context. The record describes a warning, not a memory error, and gives no score. It matters for 32-bit Tegra boards that suspend. The record says the problem started in 7.2, so older branches such as 6.12 are not affected. The fix is in 7.2.13 and 7.3. See the cve.org record.

Two network records apply to any device that has the TCP/IP stack or the tun driver. CVE-2026-99270 is a TCP use-after-free that the CNA scores 8.1 HIGH, described in the cloud section. CVE-2026-99281 changes who may attach to a persistent tun device, which VPN clients and similar programs use. Both are described below.

Embedded and IoT

Embedded boards use small drivers, a TPM or secure element, and the kernel key store. They often run an older long-term branch for years. The records below apply only if your kernel builds the named code.

CVE-2026-99218: Core dump writer wakes a thread that may already be freed

coredump_finish() releases the parked threads by clearing their task pointer and calling wake_up_process() on each one, without a reference and outside RCU. A parked thread can leave on a spurious wakeup, so try_to_wake_up() may then take a lock in freed memory. The fix holds RCU across the loop. The CNA scores it 7.0 HIGH with a local vector and high attack complexity. The bug exists since 2.6.27, and the fix is in 6.1.191, 6.6.161, 6.12.115, 6.18.60, 7.2.14 and 7.3.1. The record lists no fix for 5.10 and 5.15. Products that capture core dumps after a crash should plan this update. See the cve.org record.

CVE-2026-99224: Key type name read after the module may be unloaded

keyctl_describe_key() must keep the key type name valid while kasprintf() uses it. The type name lives in the module that provides the key type, and a privileged module unload can free it between the two formatting passes. The record gives AF_RXRPC=m as an example. The CNA scores it 7.0 HIGH with a local vector and high attack complexity. The bug exists since 3.18. Fixes are in 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.60, 7.2.14 and 7.3.1. Seven more records fix the key store in the same release: CVE-2026-99220 to CVE-2026-99226 except CVE-2026-99224, and CVE-2026-99245. See the cve.org record.

CVE-2026-99221: Trusted key accepted after a TPM unseal failure

In trusted_tpm_unseal(), if the TPM unseal operation fails and the following pcrlock() call succeeds, the success value replaces the unseal error, so the key is created anyway. The fix returns at once on an unseal failure. The record gives no score. It applies to devices that use TPM 1.2 trusted keys, in the file security/keys/trusted-keys/trusted_tpm1.c. The bug exists since 5.13. The fix is in 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.60, 7.2.14 and 7.3.1. See the cve.org record.

CVE-2026-99248: xiic I2C driver warns on every unbind

The i2c-xiic driver changed to managed runtime power management, and the teardown order then disables the clock twice. The result is a clk_core_disable() warning on every remove. The record describes a warning flood and gives no score. It applies to boards that use the xiic I2C controller. The record says the problem started in 7.1, so older long-term branches are not affected. The fix is in 7.2.13 and 7.3. See the cve.org record.

Other narrow driver records this week include CVE-2026-99257 (shared GPIO lookup), CVE-2026-99256 (device-mapper cache locking) and CVE-2026-99271 (a USB audio driver cleanup). Check them against the drivers in your device tree.

Cloud and datacenter Linux kernel CVEs

Servers and container hosts care most about the network stack, virtualization, io_uring, scheduling and network file systems. These are the records to read first.

CVE-2026-99270: TCP request socket timer use-after-free

When TCP socket migration fails at inet_ehash_insert() inside reqsk_timer_handler(), the new request socket is freed at once, but its timer may still run. The fix stops that timer first. The CNA scores it 8.1 HIGH with a network vector and high attack complexity. The bug exists since 4.2. The record lists a stable fix only for 6.18.61 and mainline 7.1. A fix in mainline 7.1 is contained in every later release, but the record lists no fix for 5.10 to 6.12, so check your tree. See the cve.org record.

CVE-2026-99246: TIPC node reset trace dump use-after-free

The tipc_node_reset_links trace event walks the link entries of a node without holding the node lock. Bearer teardown can free a link while the trace code reads it. The record includes a KASAN report that reaches the code through tipc_udp_recv. The CNA scores it 8.1 HIGH with a network vector and high attack complexity. The bug exists since 5.0, and the fix is in every branch of the table: 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.59, 7.2.13 and 7.3. It matters only on hosts that load the TIPC cluster protocol. See the cve.org record.

CVE-2026-99284: skb_zerocopy() loses the shared-fragment marker

skb_zerocopy() moves fragment descriptors but does not copy the shared-fragment flag. A packet built for nfnetlink_queue or for an Open vSwitch upcall then looks private. The ESP input path decrypts such a packet in place. The record says this lets an unprivileged user write into the page cache of a root-owned read-only file. The record gives no score, so the score does not show its weight. The bug exists since 3.14. The record lists fixes only for 6.18.61, 7.2.15 and 7.3.2, which makes it the reason 7.2 needs 7.2.15 this week. It applies to hosts that use IPsec ESP together with nfnetlink_queue or Open vSwitch. See the cve.org record.

CVE-2026-99281: tun device with no owner now needs CAP_NET_ADMIN

Before this fix, any process that could open /dev/net/tun could attach to a persistent tun device that had no owner or group. The fix requires CAP_NET_ADMIN for that case. The record says this is the only behaviour change. The record gives no score. It applies to container hosts and VPN setups that create persistent tun devices without an owner. Test any program that attaches to such a device after the update. The bug exists since 2.6.18, and the fix is in 6.18.61 and 7.3.2. See the cve.org record.

CVE-2026-99282: sch_teql use-after-free when the lower queue discipline drops a packet

The teql_master_xmit() code treats an error return from a VLAN slave as if it still owned the packet, then touches a freed buffer. The record names CONFIG_NET_SCH_TEQL, CONFIG_VLAN_8021Q and CONFIG_DUMMY as the build options it needs, plus a configured teql queue discipline on top of a VLAN device. That is a privileged network configuration, so the reach is narrow. The record gives no score. The bug exists since 2.6.33, and the fix is in 6.18.61 and 7.3.2. See the cve.org record.

CVE-2026-99227: io_uring waitid cancel reference counter can wrap

The waitid request keeps a cancel flag in bit 31 of its reference field. A failed cancel attempt still adds one to the low 31 bits, so many failed attempts can wrap the counter to zero. A later cancel can then complete the request a second time. The fix sets the flag with an atomic OR and does not add to the counter again. The CNA scores it 7.8 HIGH with a local vector. The bug exists since 6.7. The fix is in 6.12.115, 6.18.60, 7.2.14 and 7.3.1. Seven more io_uring records are live: CVE-2026-99231 (a second waitid problem, also 7.8), CVE-2026-99228, CVE-2026-99229, CVE-2026-99230, CVE-2026-99253, CVE-2026-99254 and CVE-2026-99255. See the cve.org record.

CVE-2026-99231: io_uring waitid clears its wait head before it owns the request

The wake handler clears ->head before it becomes the owner of the request. Another path can finish and free the request in that window, and the handler then writes to whatever reuses the memory. The record includes a KASAN slab use-after-free report. The CNA scores it 7.8 HIGH with a local vector. The record names 6.19 as the generic start and lists affected ranges 6.12.113 up to 6.12.115 and 6.18.52 up to 6.18.60. The fix is in 6.12.115, 6.18.60, 7.2.14 and 7.3.2. Note that the 7.3 fix version is 7.3.2 here, not 7.3.1. See the cve.org record.

CVE-2026-99269: sched_ext dispatch race when moving tasks between queues

A task can be found on a non-local dispatch queue while the CPU that dispatched it is still running ops.dequeue(). The move paths did not wait for that to finish. The fix waits in three places. The CNA scores it 7.8 HIGH with a local vector. The record says the bug started in 7.1, so only kernels with the extensible scheduler class are affected. The fix is in 7.2.14 and 7.3. See the cve.org record.

CVE-2026-100080: Xen netback statistics use-after-free (XSA-526)

When the backend tears down its queues after an error while connecting to the frontend, for example after illegal Xenstore data written by the guest, it frees the statistics data without waiting for RCU. A read through sysfs in that phase can use freed memory. The record gives no score. It applies to Xen hosts that run the network backend. Two sibling records fix related problems: CVE-2026-100081 (XSA-527, deferred free of the multicast address list) and CVE-2026-100082 (XSA-528, the block backend I/O statistics). All three are fixed in 5.10.274, 5.15.225, 6.1.192, 6.6.162, 6.12.116, 6.18.62 and 7.3.3, and they set the version target on every long-term branch this week. See the cve.org record.

CVE-2026-99258: Hyper-V guest hypercall writes to memory the guest never allocated

hv_apicid_to_vp_index() uses the per-CPU hypercall pages. In a VTL2 guest the output page exists. In an SEV-SNP confidential guest without a paravisor it does not, so the hypervisor stores the output in unallocated guest memory. The fix uses the input page for both. The record gives no score. It applies to confidential virtual machines on Hyper-V. The CNA data starts the problem at 6.16, with backport ranges that begin at 6.12.41 and 6.15.3. The fix is in 6.12.115, 6.18.59, 7.2.13 and 7.3. A related record, CVE-2026-99251, fixes an endless retry loop in Hyper-V channel setup. See the cve.org record.

CVE-2026-99272: SMB client reads past the end of a READ response

SMB2_read() copies the data length given by the server from the data offset, without checking that the range lies inside the reply. A malicious server can send a short READ reply with data offset 0 and data length 1067. The record describes a KASAN out-of-bounds read of a 448-byte receive object, reached through the symlink parser used with the mfsymlinks or SFU mount features. The record gives no score. It applies to any host that mounts an SMB share from a server it does not fully trust. The bug exists since 3.7. The record lists a fix only for 7.3.2 and mainline 7.4-rc1. Related SMB records: CVE-2026-99275 (short SESSION_SETUP replies), CVE-2026-99274 (a fiemap wild read) and, on the server side, CVE-2026-99273 (ksmbd UTF-16 terminator) and the ksmbd session records CVE-2026-99276 to CVE-2026-99280. Those five ksmbd records are listed as affecting 7.2.8 up to 7.3.1 and list a fix only in 7.3.2, so a 7.2 system stays exposed until it moves to 7.3. See the cve.org record.

Other cloud-relevant records without a separate heading: five more tracing records with a HIGH score (CVE-2026-99233, CVE-2026-99235, CVE-2026-99236, CVE-2026-99237 and CVE-2026-99238) have a local vector and need a local low-privilege account, and CVE-2026-99283 fixes a netfilter conntrack timeout for non-closing RST packets (fix listed only for 6.18.61).

Medical devices

Connected medical devices matter for this list when they use Bluetooth, TCP/IP, USB or network file systems. CVE-2026-99239 applies to wearables and monitors that use Bluetooth sockets. CVE-2026-99270 and CVE-2026-99246 apply to any connected device that accepts TCP or TIPC traffic. CVE-2026-99272 applies to a device that only mounts a clinical data share from an SMB server, because a malicious or damaged server can send the bad reply. A device that serves a share with the in-kernel SMB server should also read CVE-2026-99273 and the ksmbd session records. Medical-device patching is gated by validation and regulatory revalidation (US FDA postmarket cybersecurity guidance, EU MDR and IEC 62304), so the action is to plan the stable update through the manufacturer’s change-control process.

How to check if a CVE applies to you

Ask three questions in this order.

1. Version. Run uname -r and compare the result with the table. If it is lower than the value for your branch, the CVEs in this post may apply.
2. Configuration. Check that your kernel builds the code. For CVE-2026-99282 the record names three build options:

raghu@techveda.org:~$ zcat /proc/config.gz | grep -E 'CONFIG_NET_SCH_TEQL|CONFIG_VLAN_8021Q|CONFIG_DUMMY'
CONFIG_NET_SCH_TEQL=m
CONFIG_VLAN_8021Q=m
CONFIG_DUMMY=m

The output above is an example. If a symbol is missing or not set, that record does not apply. For records that name only a source file, check whether the file is built in your tree.

3. Reachability. This sets the order. Remote or over-the-air reach comes first, then local unprivileged users, then guest-to-host on shared hosts, then privileged or configuration-only paths.

Key takeaways

• 61 live Linux kernel CVEs were published from 1 to 7 November 2026. 10 more were rejected. None is CRITICAL, and 13 are HIGH.
• Update to at least 5.10.274, 5.15.225, 6.1.192, 6.6.162, 6.12.116, 6.18.62, 7.2.15 and 7.3.3. These equal the newest kernel.org releases, so the table is a ceiling.
• Three Xen backend records (CVE-2026-100080, CVE-2026-100081, CVE-2026-100082) raise the target by one patch level on every long-term branch.
• 48 live records have no score. Read CVE-2026-99284, CVE-2026-99281 and CVE-2026-99272 even though they are unscored.
• kernel.org marks 7.2 end of life at 7.2.15. Plan the move to 7.3.
• Medical devices: plan the stable update through the manufacturer’s change-control and revalidation process.

Frequently asked questions

How many Linux kernel CVEs were published from 1 to 7 November 2026?
NVD lists 71 records for the kernel CNA in that window. 10 were rejected, so 61 are live. The lore.kernel.org announcement list shows the same 71 announcements.

Is any of this week’s CVEs CRITICAL?
No. 13 live records carry a CNA score and all 13 are HIGH, with scores from 7.0 to 8.1. The other 48 live records have no score.

Which kernel version do I need?
Update to at least 5.10.274, 5.15.225, 6.1.192, 6.6.162, 6.12.116, 6.18.62, 7.2.15 and 7.3.3 for your branch. 7.2 reached its last release at 7.2.15, so move to 7.3.

Are any of these CVEs being exploited?
No record states that a bug is being exploited, and every live record lists a fixed stable release. The three Xen records list no mainline release. The action is to schedule the stable update.

Why are the Xen backend CVEs important for the version table?
CVE-2026-100080, CVE-2026-100081 and CVE-2026-100082 were published on 6 November and are fixed one patch level above the other records on 5.10, 5.15, 6.1, 6.6, 6.12 and 6.18. They set the minimum version on those branches.

Further reading

• linux-cve-announce archive on lore.kernel.org
• cve.org record search
• National Vulnerability Database
• kernel.org releases
• Xen security advisories