Microsoft Makers of the Windows Operating System and hundreds of products that run on it.
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any Microsoft product.
RSS Feeds for Microsoft security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in Microsoft products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by Microsoft Sorted by Most Security Vulnerabilities since 2018
Recent Microsoft Security Advisories
| Advisory | Title | Published |
|---|---|---|
| CVE-2026-6920 | Chromium: CVE-2026-6920 Out of bounds read in GPU | April 28, 2026 |
| CVE-2026-6919 | Chromium: CVE-2026-6919 Use after free in DevTools | April 28, 2026 |
| CVE-2026-23362 | CVE-2026-23362 can: bcm: fix locking for bcm_op runtime updates | April 26, 2026 |
| CVE-2026-31656 | CVE-2026-31656 drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat | April 26, 2026 |
| CVE-2026-31658 | CVE-2026-31658 net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() | April 26, 2026 |
| CVE-2026-31592 | CVE-2026-31592 KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm->lock | April 26, 2026 |
| CVE-2026-31597 | CVE-2026-31597 ocfs2: fix use-after-free in ocfs2_fault() when VM_FAULT_RETRY | April 26, 2026 |
| CVE-2026-31622 | CVE-2026-31622 NFC: digital: Bounds check NFC-A cascade depth in SDD response handler | April 26, 2026 |
| CVE-2026-31664 | CVE-2026-31664 xfrm: clear trailing padding in build_polexpire() | April 26, 2026 |
| CVE-2026-31673 | CVE-2026-31673 af_unix: read UNIX_DIAG_VFS data under unix_state_lock | April 26, 2026 |
Known Exploited Microsoft Vulnerabilities
The following Microsoft vulnerabilities have recently been marked by CISA as Known to be Exploited by threat actors.
| Title | Description | Added |
|---|---|---|
| Microsoft Windows Protection Mechanism Failure Vulnerability |
Microsoft Windows Shell contains a protection mechanism failure vulnerability that allows an unauthorized attacker to perform spoofing over a network. CVE-2026-32202 |
April 28, 2026 |
| Microsoft Defender Insufficient Granularity of Access Control Vulnerability |
Microsoft Defender contains an insufficient granularity of access control vulnerability that could allow an authorized attacker to escalate privileges locally. CVE-2026-33825 |
April 22, 2026 |
| Microsoft Office Remote Code Execution |
Microsoft Office Excel contains a remote code execution vulnerability that could allow an attacker to take complete control of an affected system if a user opens a specially crafted Excel file that includes a malformed object. CVE-2009-0238 Exploit Probability: 74.9% |
April 14, 2026 |
| Microsoft SharePoint Server Improper Input Validation Vulnerability |
Microsoft SharePoint Server contains an improper input validation vulnerability that allows an unauthorized attacker to perform spoofing over a network. CVE-2026-32201 |
April 14, 2026 |
| Microsoft Visual Basic for Applications Insecure Library Loading Vulnerability |
Microsoft Visual Basic for Applications (VBA) contains an insecure library loading vulnerability that could allow for remote code execution. CVE-2012-1854 Exploit Probability: 4.3% |
April 13, 2026 |
| Microsoft Exchange Server Deserialization of Untrusted Data Vulnerability |
Microsoft Exchange Server contains a deserialization of untrusted data that allows an authenticated attacker to achieve remote code execution. CVE-2023-21529 Exploit Probability: 23.8% |
April 13, 2026 |
| Microsoft Windows Link Following Vulnerability |
Microsoft Windows contains a link following vulnerability that allows for privilege escalation CVE-2025-60710 Exploit Probability: 18.2% |
April 13, 2026 |
| Microsoft Windows Out-of-Bounds Read Vulnerability |
Microsoft Windows Common Log File System Driver contains an out-of-bounds read vulnerability that could allow a threat actor for privileges escalation CVE-2023-36424 Exploit Probability: 7.3% |
April 13, 2026 |
| Microsoft SharePoint Deserialization of Untrusted Data Vulnerability |
Microsoft SharePoint contains a deserialization of untrusted data vulnerability that allows an unauthorized attacker to execute code over a network. CVE-2026-20963 Exploit Probability: 6.0% |
March 18, 2026 |
| Microsoft Windows Video ActiveX Control Remote Code Execution Vulnerability |
Microsoft Windows Video ActiveX Control contains a remote code execution vulnerability. An attacker could exploit the vulnerability by constructing a specially crafted Web page. When a user views the Web page, the vulnerability could allow remote code execution. An attacker who successfully exploited this vulnerability could gain the same user rights as the logged-on user. CVE-2008-0015 Exploit Probability: 81.6% |
February 17, 2026 |
| Microsoft Configuration Manager SQL Injection Vulnerability |
Microsoft Configuration Manager contains an SQL injection vulnerability. An unauthenticated attacker could exploit this vulnerability by sending specially crafted requests to the target environment which are processed in an unsafe manner enabling the attacker to execute commands on the server and/or underlying database. CVE-2024-43468 Exploit Probability: 83.3% |
February 12, 2026 |
| Microsoft Windows Type Confusion Vulnerability |
Microsoft Desktop Windows Manager contains a type confusion vulnerability that could allow an authorized attacker to elevate privileges locally. CVE-2026-21519 Exploit Probability: 4.5% |
February 10, 2026 |
| Microsoft Windows Improper Privilege Management Vulnerability |
Microsoft Windows Remote Desktop Services contains an improper privilege management vulnerability that could allow an authorized attacker to elevate privileges locally. CVE-2026-21533 Exploit Probability: 22.7% |
February 10, 2026 |
| Microsoft Internet Explorer Protection Mechanism Failure Vulnerability |
Microsoft Internet Explorer contains a protection mechanism failure vulnerability that could allow an unauthorized attacker to bypass a security feature over a network. CVE-2026-21513 Exploit Probability: 28.0% |
February 10, 2026 |
| Microsoft Windows NULL Pointer Dereference Vulnerability |
Microsoft Windows Remote Access Connection Manager contains a NULL pointer dereference that could allow an unauthorized attacker to deny service locally. CVE-2026-21525 Exploit Probability: 11.8% |
February 10, 2026 |
| Microsoft Windows Shell Protection Mechanism Failure Vulnerability |
Microsoft Windows Shell contains a protection mechanism failure vulnerability that could allow an unauthorized attacker to bypass a security feature over a network. CVE-2026-21510 Exploit Probability: 3.5% |
February 10, 2026 |
| Microsoft Office Word Reliance on Untrusted Inputs in a Security Decision Vulnerability |
Microsoft Office Word contains a reliance on untrusted inputs in a security decision vulnerability that could allow an authorized attacker to elevate privileges locally. CVE-2026-21514 Exploit Probability: 4.2% |
February 10, 2026 |
| Microsoft Office Security Feature Bypass Vulnerability |
Microsoft Office contains a security feature bypass vulnerability in which reliance on untrusted inputs in a security decision in Microsoft Office could allow an unauthorized attacker to bypass a security feature locally. CVE-2026-21509 Exploit Probability: 7.5% |
January 26, 2026 |
| Microsoft Windows Information Disclosure Vulnerability |
Microsoft Windows Desktop Windows Manager contains an information disclosure vulnerability that allows an authorized attacker to disclose information locally. CVE-2026-20805 Exploit Probability: 3.7% |
January 13, 2026 |
| Microsoft Office PowerPoint Code Injection Vulnerability |
Microsoft Office PowerPoint contains a code injection vulnerability that allows remote attackers to execute arbitrary code via a PowerPoint file with an OutlineTextRefAtom containing an invalid index value that triggers memory corruption. CVE-2009-0556 Exploit Probability: 67.9% |
January 7, 2026 |
Of the known exploited vulnerabilities above, 2 are in the top 1%, or the 99th percentile of the EPSS exploit probability rankings. 6 known exploited Microsoft vulnerabilities are in the top 5% (95th percentile or greater) of the EPSS exploit probability rankings.
Top 10 Riskiest Microsoft Vulnerabilities
Based on the current exploit probability, these Microsoft vulnerabilities are on CISA's Known Exploited vulnerabilities list (KEV) and are ranked by the current EPSS exploit probability.
| Rank | CVE | EPSS | Vulnerability |
|---|---|---|---|
| 1 | CVE-2019-0708 | 94.5% | "BlueKeep" Microsoft Windows Remote Desktop Remote Code Execution Vulnerability |
| 2 | CVE-2019-0604 | 94.4% | Microsoft SharePoint Remote Code Execution Vulnerability |
| 3 | CVE-2017-7269 | 94.4% | Microsft Windows Server 2003 R2 IIS WEBDAV buffer overflow Remote Code Execution vulnerability (COVI |
| 4 | CVE-2020-0796 | 94.4% | Microsoft SMBv3 Remote Code Execution Vulnerability |
| 5 | CVE-2020-0688 | 94.4% | Microsoft Exchange Server Key Validation Vulnerability |
| 6 | CVE-2020-1472 | 94.4% | NetLogon Privilege Escalation Vulnerability |
| 7 | CVE-2021-38647 | 94.4% | Microsoft Azure Open Management Infrastructure (OMI) Remote Code Execution Vulnerability |
| 8 | CVE-2023-29357 | 94.4% | Microsoft SharePoint Server Privilege Escalation Vulnerability |
| 9 | CVE-2017-11882 | 94.4% | Microsoft Office memory corruption vulnerability |
| 10 | CVE-2021-26855 | 94.4% | Microsoft OWA Exchange Control Panel (ECP) Exploit Chain |
By the Year
In 2026 there have been 1516 vulnerabilities in Microsoft with an average score of 7.3 out of ten. Last year, in 2025 Microsoft had 2731 security vulnerabilities published. If vulnerabilities keep coming in at the current rate, it appears that number of security vulnerabilities in Microsoft in 2026 could surpass last years number. However, the average CVE base score of the vulnerabilities in 2026 is greater by 0.17.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 1516 | 7.27 |
| 2025 | 2731 | 7.09 |
| 2024 | 2181 | 7.30 |
| 2023 | 1695 | 7.22 |
| 2022 | 1389 | 7.43 |
| 2021 | 1152 | 7.44 |
| 2020 | 1253 | 7.20 |
| 2019 | 831 | 7.09 |
| 2018 | 661 | 7.03 |
It may take a day or so for new Microsoft vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Microsoft Security Vulnerabilities
| CVE | Date | Vulnerability | Products |
|---|---|---|---|
| CVE-2026-31685 | Apr 25, 2026 |
Linux Kernel Netfilter EUI-64 Address Validation BypassIn the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_eui64: reject invalid MAC header for all packets `eui64_mt6()` derives a modified EUI-64 from the Ethernet source address and compares it with the low 64 bits of the IPv6 source address. The existing guard only rejects an invalid MAC header when `par->fragoff != 0`. For packets with `par->fragoff == 0`, `eui64_mt6()` can still reach `eth_hdr(skb)` even when the MAC header is not valid. Fix this by removing the `par->fragoff != 0` condition so that packets with an invalid MAC header are rejected before accessing `eth_hdr(skb)`. |
|
| CVE-2026-31684 | Apr 25, 2026 |
Linux Kernel CVE-2026-31684: Nested VLAN header buffer over-read in act_csumIn the Linux kernel, the following vulnerability has been resolved: net: sched: act_csum: validate nested VLAN headers tcf_csum_act() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without first ensuring that the full VLAN header is present in the linear area. If only part of an inner VLAN header is linearized, accessing h_vlan_encapsulated_proto reads past the linear area, and the following skb_pull(VLAN_HLEN) may violate skb invariants. Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path. |
|
| CVE-2026-31682 | Apr 25, 2026 |
Linearize skb before ND option parsing in Linux kernel bridge (br_nd_send)In the Linux kernel, the following vulnerability has been resolved: bridge: br_nd_send: linearize skb before parsing ND options br_nd_send() parses neighbour discovery options from ns->opt[] and assumes that these options are in the linear part of request. Its callers only guarantee that the ICMPv6 header and target address are available, so the option area can still be non-linear. Parsing ns->opt[] in that case can access data past the linear buffer. Linearize request before option parsing and derive ns from the linear network header. |
|
| CVE-2026-31681 | Apr 25, 2026 |
Linux kernel: netfilter xt_multiport range validation flawIn the Linux kernel, the following vulnerability has been resolved: netfilter: xt_multiport: validate range encoding in checkentry ports_match_v1() treats any non-zero pflags entry as the start of a port range and unconditionally consumes the next ports[] element as the range end. The checkentry path currently validates protocol, flags and count, but it does not validate the range encoding itself. As a result, malformed rules can mark the last slot as a range start or place two range starts back to back, leaving ports_match_v1() to step past the last valid ports[] element while interpreting the rule. Reject malformed multiport v1 rules in checkentry by validating that each range start has a following element and that the following element is not itself marked as another range start. |
|
| CVE-2026-31680 | Apr 25, 2026 |
Linux kernel: RCU race in ipv6 flowlabel /proc reading leads to crashIn the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file RCU read-side lock and prints `fl->opt->opt_nflen` when an option block is present. Exclusive flowlabels currently free `fl->opt` as soon as `fl->users` drops to zero in `fl_release()`. However, the surrounding `struct ip6_flowlabel` remains visible in the global hash table until later garbage collection removes it and `fl_free_rcu()` finally tears it down. A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that early `kfree()` and dereference freed option state, triggering a crash in `ip6fl_seq_show()`. Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches the lifetime already required for the enclosing flowlabel while readers can still reach it under RCU. |
|
| CVE-2026-31679 | Apr 25, 2026 |
Open vSwitch: Invalid MPLS Payload Length in SET/SET_MASKED ActionsIn the Linux kernel, the following vulnerability has been resolved: openvswitch: validate MPLS set/set_masked payload length validate_set() accepted OVS_KEY_ATTR_MPLS as variable-sized payload for SET/SET_MASKED actions. In action handling, OVS expects fixed-size MPLS key data (struct ovs_key_mpls). Use the already normalized key_len (masked case included) and reject non-matching MPLS action key sizes. Reject invalid MPLS action payload lengths early. |
|
| CVE-2026-31678 | Apr 25, 2026 |
Race Condition in Open vSwitch Tunnel Destruction via Netdev ReleaseIn the Linux kernel, the following vulnerability has been resolved: openvswitch: defer tunnel netdev_put to RCU release ovs_netdev_tunnel_destroy() may run after NETDEV_UNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev. Do not release vport->dev in ovs_netdev_tunnel_destroy(). Instead, let vport_netdev_free() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL. |
|
| CVE-2026-31677 | Apr 25, 2026 |
Linux Kernel af_alg RX SG Extraction: Buffer Budget LimitationIn the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - limit RX SG extraction by receive buffer budget Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget. af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request. If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero. |
|
| CVE-2026-31676 | Apr 25, 2026 |
Linux Kernel RxRPC: Response Only During Service Challenge VulnerabilityIn the Linux kernel, the following vulnerability has been resolved: rxrpc: only handle RESPONSE during service challenge Only process RESPONSE packets while the service connection is still in RXRPC_CONN_SERVICE_CHALLENGING. Check that state under state_lock before running response verification and security initialization, then use a local secured flag to decide whether to queue the secured-connection work after the state transition. This keeps duplicate or late RESPONSE packets from re-running the setup path and removes the unlocked post-transition state test. |
|
| CVE-2026-31675 | Apr 25, 2026 |
Linux kernel OOB memory via netem packet corruption on non-linear packetsIn the Linux kernel, the following vulnerability has been resolved: net/sched: sch_netem: fix out-of-bounds access in packet corruption In netem_enqueue(), the packet corruption logic uses get_random_u32_below(skb_headlen(skb)) to select an index for modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0. Passing 0 to get_random_u32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access. Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic. |
|
| CVE-2026-31674 | Apr 25, 2026 |
Linux Kernel Netfilter: Reject oversized rt addrnr in ip6t_rt match ruleIn the Linux kernel, the following vulnerability has been resolved: netfilter: ip6t_rt: reject oversized addrnr in rt_mt6_check() Reject rt match rules whose addrnr exceeds IP6T_RT_HOPS. rt_mt6() expects addrnr to stay within the bounds of rtinfo->addrs[]. Validate addrnr during rule installation so malformed rules are rejected before the match logic can use an out-of-range value. |
|
| CVE-2026-31673 | Apr 25, 2026 |
Linux Kernel: af_unix UNIX_DIAG_VFS Read Race (CVE-2026-31673)In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. Meanwhile, unix_release_sock() clears u->path under unix_state_lock() and drops the path reference after unlocking. Read the inode and device numbers for UNIX_DIAG_VFS while holding unix_state_lock(), then emit the netlink attribute after dropping the lock. This keeps the VFS data stable while the reply is being built. |
|
| CVE-2026-41907 | Apr 24, 2026 |
uuidjs uuid <14.0.0 silent partial buffer writesuuid is for the creation of RFC9562 (formerly RFC4122) UUIDs. Prior to 14.0.0, v3, v5, and v6 accept external output buffers but do not reject out-of-range writes (small buf or large offset). This allows silent partial writes into caller-provided buffers. This vulnerability is fixed in 14.0.0. |
|
| CVE-2026-41681 | Apr 24, 2026 |
rust-openssl Buffer Overflow in EVP_DigestFinal (0.10.39-0.10.78)rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.10.39 to before 0.10.78, EVP_DigestFinal() always writes EVP_MD_CTX_size(ctx) to the out buffer. If out is smaller than that, MdCtxRef::digest_final() writes past its end, usually corrupting the stack. This is reachable from safe Rust. This vulnerability is fixed in 0.10.78. |
|
| CVE-2026-41678 | Apr 24, 2026 |
Rust OpenSSL: unsafe out-of-bounds write in aes::unwrap_key() before 0.10.78rust-openssl provides OpenSSL bindings for the Rust programming language. From to before 0.10.78, aes::unwrap_key() contains an incorrect assertion: it checks that out.len() + 8 <= in_.len(), but this condition is reversed. The intended invariant is out.len() >= in_.len() - 8, ensuring the output buffer is large enough. Because of the inverted check, the function only accepts buffers at or below the minimum required size and rejects larger ones. If a smaller buffer is provided the function will write past the end of out by in_.len() - 8 - out.len() bytes, causing an out-of-bounds write from a safe public function. This vulnerability is fixed in 0.10.78. |
|
| CVE-2026-41677 | Apr 24, 2026 |
Rust-OpenSSL 0.9.0-0.10.78 PEM Callback Over-Read in OpenSSL bindingrust-openssl provides OpenSSL bindings for the Rust programming language. From 0.9.0 to before 0.10.78, the *_from_pem_callback APIs did not validate the length returned by the user's callback. A password callback that returns a value larger than the buffer it was given can cause some versions of OpenSSL to over-read this buffer. OpenSSL 3.x is not affected by this. This vulnerability is fixed in 0.10.78. |
|
| CVE-2026-41676 | Apr 24, 2026 |
rust-openssl 0.9.27-0.10.77 Deriver::derive OOB causing overflow (bad len)rust-openssl provides OpenSSL bindings for the Rust programming language. From 0.9.27 to before 0.10.78, Deriver::derive (and PkeyCtxRef::derive) sets len = buf.len() and passes it as the in/out length to EVP_PKEY_derive, relying on OpenSSL to honor it. On OpenSSL 1.1.x, X25519, X448, DH and HKDF-extract ignore the incoming *keylen, unconditionally writing the full shared secret (32/56/prime-size bytes). A caller passing a short slice gets a heap/stack overflow from safe code. OpenSSL 3.x providers do check, so this only impacts older OpenSSL. This vulnerability is fixed in 0.10.78. |
|
| CVE-2026-41140 | Apr 24, 2026 |
Poetry <2.3.4 Path Traversal in tarfile extractionPoetry is a dependency manager for Python. Prior to 2.3.4, the extractall() function in src/poetry/utils/helpers.py:410-426 extracts sdist tarballs without path traversal protection on Python versions where tarfile.data_filter is unavailable. Considering only Python versions which are still supported by Poetry, these are 3.10.0 - 3.10.12 and 3.11.0 - 3.11.4. This vulnerability is fixed in 2.3.4. |
|
| CVE-2026-41079 | Apr 24, 2026 |
CUPS 2.4.17: OOB read via crafted SNMP response (pre2.4.17)OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to 2.4.17, a network-adjacent attacker can send a crafted SNMP response to the CUPS SNMP backend that causes an out-of-bounds read of up to 176 bytes past a stack buffer. The leaked memory is converted from UTF-16 to UTF-8 and stored as printer supply description strings, which are subsequently visible to authenticated users via IPP Get-Printer-Attributes responses and the CUPS web interface. This vulnerability is fixed in 2.4.17. |
|
| CVE-2026-41411 | Apr 24, 2026 |
Vim 9.2.0357-Pre: Cmd Injection via Tag File ProcessingVim is an open source, command line text editor. Prior to 9.2.0357, A command injection vulnerability exists in Vim's tag file processing. When resolving a tag, the filename field from the tags file is passed through wildcard expansion to resolve environment variables and wildcards. If the filename field contains backtick syntax (e.g., `command`), Vim executes the embedded command via the system shell with the full privileges of the running user. |
|
| CVE-2026-41066 | Apr 24, 2026 |
lxml <6.1.0 XML Parser: LFR via resolve_entities=Truelxml is a library for processing XML and HTML in the Python language. Prior to 6.1.0, using either of the two parsers in the default configuration (with resolve_entities=True) allows untrusted XML input to read local files. Setting the resolve_entities option explicitly to resolve_entities='internal' or resolve_entities=False disables the local file access. This vulnerability is fixed in 6.1.0. |
|
| CVE-2026-31672 | Apr 24, 2026 |
Linux Kernel RT2x00USB devres Lifetime Memory Leak FixIn the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00usb: fix devres lifetime USB drivers bind to USB interfaces and any device managed resources should have their lifetime tied to the interface rather than parent USB device. This avoids issues like memory leaks when drivers are unbound without their devices being physically disconnected (e.g. on probe deferral or configuration changes). Fix the USB anchor lifetime so that it is released on driver unbind. |
|
| CVE-2026-31671 | Apr 24, 2026 |
Linux Kernel: Zero Padding Leak in xfrm_user Report StructureIn the Linux kernel, the following vulnerability has been resolved: xfrm_user: fix info leak in build_report() struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables. |
|
| CVE-2026-31670 | Apr 24, 2026 |
Linux kernel: rfkill event overflow OOM vulnerabilityIn the Linux kernel, the following vulnerability has been resolved: net: rfkill: prevent unlimited numbers of rfkill events from being created Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this. |
|
| CVE-2026-31669 | Apr 24, 2026 |
Linux Kernel MPTCP slab-UAF in __inet_lookup_establishedIn the Linux kernel, the following vulnerability has been resolved: mptcp: fix slab-use-after-free in __inet_lookup_established The ehash table lookups are lockless and rely on SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability during RCU read-side critical sections. Both tcp_prot and tcpv6_prot have their slab caches created with this flag via proto_register(). However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into tcpv6_prot_override during inet_init() (fs_initcall, level 5), before inet6_init() (module_init/device_initcall, level 6) has called proto_register(&tcpv6_prot). At that point, tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab remains NULL permanently. This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so when these sockets are freed without SOCK_RCU_FREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcu_read_lock can then access freed memory, triggering a slab-use-after-free in __inet_lookup_established. Fix this by splitting the IPv6-specific initialization out of mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called from mptcp_proto_v6_init() before protocol registration. This ensures tcpv6_prot_override.slab correctly inherits the SLAB_TYPESAFE_BY_RCU slab cache. |
|
| CVE-2026-31668 | Apr 24, 2026 |
Linux Kernel seg6 lwtunnel dst_cache split to fix SID lookup bypassIn the Linux kernel, the following vulnerability has been resolved: seg6: separate dst_cache for input and output paths in seg6 lwtunnel The seg6 lwtunnel uses a single dst_cache per encap route, shared between seg6_input_core() and seg6_output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup. Fix this by splitting the cache into cache_input and cache_output, so each path maintains its own cached dst independently. |
|
| CVE-2026-31667 | Apr 24, 2026 |
Linux kernel UINPUT circular lockdep dependency fixedIn the Linux kernel, the following vulnerability has been resolved: Input: uinput - fix circular locking dependency with ff-core A lockdep circular locking dependency warning can be triggered reproducibly when using a force-feedback gamepad with uinput (for example, playing ELDEN RING under Wine with a Flydigi Vader 5 controller): ff->mutex -> udev->mutex -> input_mutex -> dev->mutex -> ff->mutex The cycle is caused by four lock acquisition paths: 1. ff upload: input_ff_upload() holds ff->mutex and calls uinput_dev_upload_effect() -> uinput_request_submit() -> uinput_request_send(), which acquires udev->mutex. 2. device create: uinput_ioctl_handler() holds udev->mutex and calls uinput_create_device() -> input_register_device(), which acquires input_mutex. 3. device register: input_register_device() holds input_mutex and calls kbd_connect() -> input_register_handle(), which acquires dev->mutex. 4. evdev release: evdev_release() calls input_flush_device() under dev->mutex, which calls input_ff_flush() acquiring ff->mutex. Fix this by introducing a new state_lock spinlock to protect udev->state and udev->dev access in uinput_request_send() instead of acquiring udev->mutex. The function only needs to atomically check device state and queue an input event into the ring buffer via uinput_dev_event() -- both operations are safe under a spinlock (ktime_get_ts64() and wake_up_interruptible() do not sleep). This breaks the ff->mutex -> udev->mutex link since a spinlock is a leaf in the lock ordering and cannot form cycles with mutexes. To keep state transitions visible to uinput_request_send(), protect writes to udev->state in uinput_create_device() and uinput_destroy_device() with the same state_lock spinlock. Additionally, move init_completion(&request->done) from uinput_request_send() to uinput_request_submit() before uinput_request_reserve_slot(). Once the slot is allocated, uinput_flush_requests() may call complete() on it at any time from the destroy path, so the completion must be initialised before the request becomes visible. Lock ordering after the fix: ff->mutex -> state_lock (spinlock, leaf) udev->mutex -> state_lock (spinlock, leaf) udev->mutex -> input_mutex -> dev->mutex -> ff->mutex (no back-edge) |
|
| CVE-2026-31665 | Apr 24, 2026 |
Linux Kernel Netfilter nft_ct UAF in timeout object destroyIn the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: fix use-after-free in timeout object destroy nft_ct_timeout_obj_destroy() frees the timeout object with kfree() immediately after nf_ct_untimeout(), without waiting for an RCU grace period. Concurrent packet processing on other CPUs may still hold RCU-protected references to the timeout object obtained via rcu_dereference() in nf_ct_timeout_data(). Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer freeing until after an RCU grace period, matching the approach already used in nfnetlink_cttimeout.c. KASAN report: BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0 Read of size 4 at addr ffff8881035fe19c by task exploit/80 Call Trace: nf_conntrack_tcp_packet+0x1381/0x29d0 nf_conntrack_in+0x612/0x8b0 nf_hook_slow+0x70/0x100 __ip_local_out+0x1b2/0x210 tcp_sendmsg_locked+0x722/0x1580 __sys_sendto+0x2d8/0x320 Allocated by task 75: nft_ct_timeout_obj_init+0xf6/0x290 nft_obj_init+0x107/0x1b0 nf_tables_newobj+0x680/0x9c0 nfnetlink_rcv_batch+0xc29/0xe00 Freed by task 26: nft_obj_destroy+0x3f/0xa0 nf_tables_trans_destroy_work+0x51c/0x5c0 process_one_work+0x2c4/0x5a0 |
|
| CVE-2026-31664 | Apr 24, 2026 |
Linux Kernel xfrm: Uninitialized Padding Leak in build_polexpire()In the Linux kernel, the following vulnerability has been resolved: xfrm: clear trailing padding in build_polexpire() build_expire() clears the trailing padding bytes of struct xfrm_user_expire after setting the hard field via memset_after(), but the analogous function build_polexpire() does not do this for struct xfrm_user_polexpire. The padding bytes after the __u8 hard field are left uninitialized from the heap allocation, and are then sent to userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners, leaking kernel heap memory contents. Add the missing memset_after() call, matching build_expire(). |
|
| CVE-2026-31662 | Apr 24, 2026 |
Linux Kernel TIPC bc_ackers Underflow FixIn the Linux kernel, the following vulnerability has been resolved: tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round. Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated. Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path. |
|
| CVE-2026-31663 | Apr 24, 2026 |
Linux kernel: race in xfrm_input_resume causes device teardownIn the Linux kernel, the following vulnerability has been resolved: xfrm: hold dev ref until after transport_finish NF_HOOK After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set. |
|
| CVE-2026-31660 | Apr 24, 2026 |
Linux Kernel nfc pn533 skb Allocation Bug Leaks Null DerefIn the Linux kernel, the following vulnerability has been resolved: nfc: pn533: allocate rx skb before consuming bytes pn532_receive_buf() reports the number of accepted bytes to the serdev core. The current code consumes bytes into recv_skb and may already hand a complete frame to pn533_recv_frame() before allocating a fresh receive buffer. If that alloc_skb() fails, the callback returns 0 even though it has already consumed bytes, and it leaves recv_skb as NULL for the next receive callback. That breaks the receive_buf() accounting contract and can also lead to a NULL dereference on the next skb_put_u8(). Allocate the receive skb lazily before consuming the next byte instead. If allocation fails, return the number of bytes already accepted. |
|
| CVE-2026-31659 | Apr 24, 2026 |
Linux Kernel: batman-adv Reject Oversized Global TT Response TVLV WrapIn the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. When a remote originator advertises a large enough global TT, the TT payload length plus the VLAN header offset can exceed 65535 and wrap before kmalloc(). The full-table response path still uses the original TT payload length when it fills tt_change, so the wrapped allocation is too small and batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object before the later packet-size check runs. Fix this by rejecting TT responses whose TVLV value length cannot fit in the 16-bit TVLV payload length field. |
|
| CVE-2026-31658 | Apr 24, 2026 |
Linux Kernel: altera-tse skb leak on DMA map errorIn the Linux kernel, the following vulnerability has been resolved: net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit() When dma_map_single() fails in tse_start_xmit(), the function returns NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the stack the packet was consumed, the skb is never freed, leaking memory on every DMA mapping failure. Add dev_kfree_skb_any() before returning to properly free the skb. |
|
| CVE-2026-31657 | Apr 24, 2026 |
Linux batadv BLA claim pointer deref potential use-after-freeIn the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. The netlink claim dump path dereferences claim->backbone_gw->orig and takes claim->backbone_gw->crc_lock without pinning the underlying backbone gateway. batadv_bla_check_claim() still has the same naked pointer access pattern. Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate on a stable gateway reference until the read-side work is complete. This keeps the dump and claim-check paths aligned with the lifetime rules introduced for the other BLA claim readers. |
|
| CVE-2026-31656 | Apr 24, 2026 |
UAF/Refcnt Underflow in Intel i915 GPU DriverIn the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. The heartbeat worker reads engine->heartbeat.systole and calls i915_request_put() on it when the request is complete, but clears the pointer in a separate, non-atomic step. Concurrently, a request retirement on another CPU can drop the engine wakeref to zero, triggering __engine_park() -> intel_engine_park_heartbeat(). If the heartbeat timer is pending at that point, cancel_delayed_work() returns true and intel_engine_park_heartbeat() reads the stale non-NULL systole pointer and calls i915_request_put() on it again, causing a refcount underflow: ``` <4> [487.221889] Workqueue: i915-unordered engine_retire [i915] <4> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0 ... <4> [487.222707] Call Trace: <4> [487.222711] <TASK> <4> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915] <4> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915] <4> [487.223566] __engine_park+0xb9/0x650 [i915] <4> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915] <4> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915] <4> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915] <4> [487.225238] intel_context_exit+0xf1/0x1b0 [i915] <4> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915] <4> [487.226178] i915_request_retire+0x1c/0x40 [i915] <4> [487.226625] engine_retire+0x122/0x180 [i915] <4> [487.227037] process_one_work+0x239/0x760 <4> [487.227060] worker_thread+0x200/0x3f0 <4> [487.227068] ? __pfx_worker_thread+0x10/0x10 <4> [487.227075] kthread+0x10d/0x150 <4> [487.227083] ? __pfx_kthread+0x10/0x10 <4> [487.227092] ret_from_fork+0x3d4/0x480 <4> [487.227099] ? __pfx_kthread+0x10/0x10 <4> [487.227107] ret_from_fork_asm+0x1a/0x30 <4> [487.227141] </TASK> ``` Fix this by replacing the non-atomic pointer read + separate clear with xchg() in both racing paths. xchg() is a single indivisible hardware instruction that atomically reads the old pointer and writes NULL. This guarantees only one of the two concurrent callers obtains the non-NULL pointer and performs the put, the other gets NULL and skips it. (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42) |
|
| CVE-2026-31655 | Apr 24, 2026 |
Linux kernel: imx8mp-blk-ctrl keeps NOC_HDCP clock enabled to avoid hangIn the Linux kernel, the following vulnerability has been resolved: pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled Keep the NOC_HDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake. |
|
| CVE-2026-31651 | Apr 24, 2026 |
Linux Kernel mmc: vub300 NULL-pointer deref on disconnectIn the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix NULL-deref on disconnect Make sure to deregister the controller before dropping the reference to the driver data on disconnect to avoid NULL-pointer dereferences or use-after-free. |
|
| CVE-2026-31649 | Apr 24, 2026 |
Linux Kernel stmmac Integer Underflow in Chain ModeIn the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix integer underflow in chain mode The jumbo_frm() chain-mode implementation unconditionally computes len = nopaged_len - bmax; where nopaged_len = skb_headlen(skb) (linear bytes only) and bmax is BUF_SIZE_8KiB or BUF_SIZE_2KiB. However, the caller stmmac_xmit() decides to invoke jumbo_frm() based on skb->len (total length including page fragments): is_jumbo = stmmac_is_jumbo_frm(priv, skb->len, enh_desc); When a packet has a small linear portion (nopaged_len <= bmax) but a large total length due to page fragments (skb->len > bmax), the subtraction wraps as an unsigned integer, producing a huge len value (~0xFFFFxxxx). This causes the while (len != 0) loop to execute hundreds of thousands of iterations, passing skb->data + bmax * i pointers far beyond the skb buffer to dma_map_single(). On IOMMU-less SoCs (the typical deployment for stmmac), this maps arbitrary kernel memory to the DMA engine, constituting a kernel memory disclosure and potential memory corruption from hardware. Fix this by introducing a buf_len local variable clamped to min(nopaged_len, bmax). Computing len = nopaged_len - buf_len is then always safe: it is zero when the linear portion fits within a single descriptor, causing the while (len != 0) loop to be skipped naturally, and the fragment loop in stmmac_xmit() handles page fragments afterward. |
|
| CVE-2026-31646 | Apr 24, 2026 |
Linux Kernel lan966x Driver: page_pool Create Err Handling Fix (CVE-2026-31646)In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page_pool error handling in lan966x_fdma_rx_alloc_page_pool() page_pool_create() can return an ERR_PTR on failure. The return value is used unconditionally in the loop that follows, passing the error pointer through xdp_rxq_info_reg_mem_model() into page_pool_use_xdp_mem(), which dereferences it, causing a kernel oops. Add an IS_ERR check after page_pool_create() to return early on failure. |
|
| CVE-2026-31645 | Apr 24, 2026 |
Linux Kernel: lan966x Page Pool Leak in Error Paths (CVE-2026-31645)In the Linux kernel, the following vulnerability has been resolved: net: lan966x: fix page pool leak in error paths lan966x_fdma_rx_alloc() creates a page pool but does not destroy it if the subsequent fdma_alloc_coherent() call fails, leaking the pool. Similarly, lan966x_fdma_init() frees the coherent DMA memory when lan966x_fdma_tx_alloc() fails but does not destroy the page pool that was successfully created by lan966x_fdma_rx_alloc(), leaking it. Add the missing page_pool_destroy() calls in both error paths. |
|
| CVE-2026-31642 | Apr 24, 2026 |
Linux Kernel rxrpc RCU Deletion Improper Call RemovalIn the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix call removal to use RCU safe deletion Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop. This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by: Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that. rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs. |
|
| CVE-2026-31639 | Apr 24, 2026 |
Linux kernel: rxrpc key ref leak from call->key not releasedIn the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix key reference count leak from call->key When creating a client call in rxrpc_alloc_client_call(), the code obtains a reference to the key. This is never cleaned up and gets leaked when the call is destroyed. Fix this by freeing call->key in rxrpc_destroy_call(). Before the patch, it shows the key reference counter elevated: $ cat /proc/keys | grep afs@54321 1bffe9cd I--Q--i 8053480 4169w 3b010000 1000 1000 rxrpc afs@54321: ka $ After the patch, the invalidated key is removed when the code exits: $ cat /proc/keys | grep afs@54321 $ |
|
| CVE-2026-31638 | Apr 24, 2026 |
Linux Kernel: rxrpc Implicit-End Error Path Causes Kernel CrashIn the Linux kernel, the following vulnerability has been resolved: rxrpc: Only put the call ref if one was acquired rxrpc_input_packet_on_conn() can process a to-client packet after the current client call on the channel has already been torn down. In that case chan->call is NULL, rxrpc_try_get_call() returns NULL and there is no reference to drop. The client-side implicit-end error path does not account for that and unconditionally calls rxrpc_put_call(). This turns a protocol error path into a kernel crash instead of rejecting the packet. Only drop the call reference if one was actually acquired. Keep the existing protocol error handling unchanged. |
|
| CVE-2026-31637 | Apr 24, 2026 |
Linux Kernel RXRPC RXKAD Ticket Decrypt OOB ParsingIn the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails. |
|
| CVE-2026-31634 | Apr 24, 2026 |
Linux Kernel: RXRPC Server Keyring Refcount LeakIn the Linux kernel, the following vulnerability has been resolved: rxrpc: fix reference count leak in rxrpc_server_keyring() This patch fixes a reference count leak in rxrpc_server_keyring() by checking if rx->securities is already set. |
|
| CVE-2026-31630 | Apr 24, 2026 |
Linux Kernel: RxRPC procfs Address Buffer Overflow via %pISpc FormatterIn the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte stack buffers with "%pISpc". That is too small for the longest current-tree IPv6-with-port form the formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50 visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50] buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier mapped-v4 example |
|
| CVE-2026-31629 | Apr 24, 2026 |
Linux kernel LLCP double free due to missing return (UAF)In the Linux kernel, the following vulnerability has been resolved: nfc: llcp: add missing return after LLCP_CLOSED checks In nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc(), when the socket state is LLCP_CLOSED, the code correctly calls release_sock() and nfc_llcp_sock_put() but fails to return. Execution falls through to the remainder of the function, which calls release_sock() and nfc_llcp_sock_put() again. This results in a double release_sock() and a refcount underflow via double nfc_llcp_sock_put(), leading to a use-after-free. Add the missing return statements after the LLCP_CLOSED branches in both functions to prevent the fall-through. |
|
| CVE-2026-31628 | Apr 24, 2026 |
Linux Kernel: Zen1 HW Divider Leakage via FPDSSIn the Linux kernel, the following vulnerability has been resolved: x86/CPU: Fix FPDSS on Zen1 Zen1's hardware divider can leave, under certain circumstances, partial results from previous operations. Those results can be leaked by another, attacker thread. Fix that with a chicken bit. |
|
| CVE-2026-31627 | Apr 24, 2026 |
Linux kernel i2c SMBUS sizeverify vulnerabilityIn the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. This is the same logic that was added in commit a6e04f05ce0b ("i2c: tegra: check msg length in SMBUS block read") to the i2c tegra driver. |