https://example.github.io/cyber-rss CVEs, zero-days, exploits, proof-of-concept code, patch advisories, and vendor security bulletins. https://www.rssboard.org/rss-specification cyber-rss-aggregator en Tue, 11 Aug 2026 02:30:42 +0000 https://discuss.google.dev/t/trusted-automation-with-google-antigravity-scaling-secure-finance-integrations-from-40-days-to-5/383313 <p>Article URL: https://discuss.google.dev/t/trusted-automation-with-google-antigravity-scaling-secure-finance-integrations-from-40-days-to-5/383313 Comments URL: https://news.ycombinator.com/item?id=49249986 Points: 9 # Comments: 4</p><p><strong>Source:</strong> Hacker News (vulnerability filter)</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.63; also threat_intel 0.36)</p> a20fef11884db4d317455aea046e6907 bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 21:27:02 +0000 https://broadsheet.sh <p>Article URL: https://broadsheet.sh Comments URL: https://news.ycombinator.com/item?id=49249895 Points: 2 # Comments: 0</p><p><strong>Source:</strong> Hacker News (vulnerability filter)</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.42; also threat_intel 0.36)</p> a68d9fe5ca6a1bbac9ac237df90dfd82 bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 21:18:51 +0000 https://www.bleepingcomputer.com/news/security/openai-releases-chatgpt-56-cyber-but-its-only-for-approved-users/ <p>OpenAI has developed a new model called &quot;GPT 5.6 Cyber,&quot; designed for vulnerability research, penetration testing, incident response, and remediation. [...]</p><p><strong>Source:</strong> BleepingComputer</p><p><strong>Tags:</strong> Security, Artificial Intelligence</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.52; also cyber_attacks 0.70)</p> 87366ebf9d600daf308a592246e7548b Security Artificial Intelligence bucket:cyber_attacks bucket:vulnerabilities Mon, 10 Aug 2026 19:24:40 +0000 https://support.apple.com/en-us/148170 <p>Article URL: https://support.apple.com/en-us/148170 Comments URL: https://news.ycombinator.com/item?id=49247537 Points: 2 # Comments: 0</p><p><strong>Source:</strong> Hacker News (vulnerability filter)</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.85; also threat_intel 0.36)</p> 0a8429560ff4db32cbe9bf3f364d6010 bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 18:16:54 +0000 https://alphatheta.com/en/information/important-notice-security-vulnerability-in-pro-dj-link/ <p>Article URL: https://alphatheta.com/en/information/important-notice-security-vulnerability-in-pro-dj-link/ Comments URL: https://news.ycombinator.com/item?id=49247461 Points: 15 # Comments: 10</p><p><strong>Source:</strong> Hacker News (vulnerability filter)</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.42; also threat_intel 0.36)</p> 9b7bf62fcaeb950a240c52160d1ec679 bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 18:11:52 +0000 https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2026:52968.json <p>Red Hat security advisory RHSA-2026:52968. Severity: important. Addresses CVE-2026-13149, CVE-2026-15927, CVE-2026-39822, CVE-2026-42504, CVE-2026-54058, CVE-2026-54060, CVE-2026-55379, CVE-2026-55380, CVE-2026-57231, CVE-2026-59197.</p><p><strong>Source:</strong> Red Hat Security Advisories</p><p><strong>Tags:</strong> Security Advisory, Vulnerability, Red Hat, important, CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also threat_intel 0.68)</p> 2e3d4d710709f9fbb5876ba01b6dbcf2 Security Advisory Vulnerability Red Hat important CVE bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 17:58:19 +0000 https://thehackernews.com/2026/08/china-linked-hackers-deploy-new.html <p>Microsoft has disclosed that Storm-1175, a financially motivated threat actor linked to China, has deployed a previously undocumented ransomware strain called StormEncryptor. The use of StormEncryptor marks a shift from the adversary&#x27;s previous use of Medusa ransomware, the Microsoft Threat Intelligence Team said. &quot;StormEncryptor is written in C++ and appends the file name extension .encrypted</p><p><strong>Source:</strong> The Hacker News</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.53; also cyber_attacks 0.98, threat_intel 0.88)</p> 4c624f6c9bd5a27e21068cdbd69f5eda bucket:cyber_attacks bucket:threat_intel bucket:vulnerabilities Mon, 10 Aug 2026 16:38:37 +0000 https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2026:52946.json <p>Red Hat security advisory RHSA-2026:52946. Severity: critical. Addresses CVE-2026-27145, CVE-2026-33376, CVE-2026-33377, CVE-2026-53492, CVE-2026-55677, CVE-2026-55969, CVE-2026-66801.</p><p><strong>Source:</strong> Red Hat Security Advisories</p><p><strong>Tags:</strong> Security Advisory, Vulnerability, Red Hat, critical, CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also threat_intel 0.68)</p> 42efdc775ae0ba3de1ebdbd9fb3793ee Security Advisory Vulnerability Red Hat critical CVE bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 16:32:57 +0000 https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2026:52930.json <p>Red Hat security advisory RHSA-2026:52930. Severity: important. Addresses CVE-2026-42198.</p><p><strong>Source:</strong> Red Hat Security Advisories</p><p><strong>Tags:</strong> Security Advisory, Vulnerability, Red Hat, important, CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also threat_intel 0.68)</p> e8c6128c018a1ef7493f1a556f433318 Security Advisory Vulnerability Red Hat important CVE bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 16:19:48 +0000 https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2026:52929.json <p>Red Hat security advisory RHSA-2026:52929. Severity: important. Addresses CVE-2026-42198.</p><p><strong>Source:</strong> Red Hat Security Advisories</p><p><strong>Tags:</strong> Security Advisory, Vulnerability, Red Hat, important, CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also threat_intel 0.68)</p> dc0b01408b91f58a1871520a6721beb4 Security Advisory Vulnerability Red Hat important CVE bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 16:09:23 +0000 https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2026:52928.json <p>Red Hat security advisory RHSA-2026:52928. Severity: important. Addresses CVE-2026-42198.</p><p><strong>Source:</strong> Red Hat Security Advisories</p><p><strong>Tags:</strong> Security Advisory, Vulnerability, Red Hat, important, CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also threat_intel 0.68)</p> f724dd6db84caa27d18174e8bd7cd02f Security Advisory Vulnerability Red Hat important CVE bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 15:40:43 +0000 https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2026:52912.json <p>Red Hat security advisory RHSA-2026:52912. Severity: important. Addresses CVE-2026-56852.</p><p><strong>Source:</strong> Red Hat Security Advisories</p><p><strong>Tags:</strong> Security Advisory, Vulnerability, Red Hat, important, CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also threat_intel 0.68)</p> c3c3d39c5892d3eb345e2744675fa15e Security Advisory Vulnerability Red Hat important CVE bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 15:02:29 +0000 https://thehackernews.com/2026/08/weekly-recap-ai-goes-rogue-metabase-0.html <p>A lot of security problems still begin with someone doing a completely normal thing. Cloning a repo. Answering a call. Leaving a box exposed. Trusting the default. That pretty much covers the mood this week. Old bugs are back, supply chains are getting stranger, and some exploit paths are so short you wonder what was supposed to stop them in the first place. That’s only part of it. Here’s</p><p><strong>Source:</strong> The Hacker News</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.87; also cyber_attacks 0.93, threat_intel 0.56)</p> ab9fcef0eed7ce972e79363eeeffbc9c bucket:cyber_attacks bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 15:00:29 +0000 https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2026:52910.json <p>Red Hat security advisory RHSA-2026:52910. Severity: important. Addresses CVE-2026-25681, CVE-2026-27136, CVE-2026-39828, CVE-2026-39829, CVE-2026-39830, CVE-2026-39831, CVE-2026-39832, CVE-2026-39835, CVE-2026-42508.</p><p><strong>Source:</strong> Red Hat Security Advisories</p><p><strong>Tags:</strong> Security Advisory, Vulnerability, Red Hat, important, CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also threat_intel 0.68)</p> 494083bb362462ea9cfaa5fd4347a745 Security Advisory Vulnerability Red Hat important CVE bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 14:51:20 +0000 https://www.bleepingcomputer.com/news/security/cisa-sonicwall-sma1000-flaws-now-exploited-by-ransomware-gangs/ <p>CISA has confirmed that ransomware gangs have begun exploiting two recently patched SonicWall SMA1000 vulnerabilities, including a maximum-severity server-side request forgery (SSRF) flaw. [...]</p><p><strong>Source:</strong> BleepingComputer</p><p><strong>Tags:</strong> Security</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.91; also cyber_attacks 0.90)</p> 0ae2ad26aa145b0d1ac8b654f9205f9b Security bucket:vulnerabilities bucket:cyber_attacks Mon, 10 Aug 2026 14:34:32 +0000 https://www.securityweek.com/cisco-warns-of-high-severity-clamav-vulnerabilities-with-public-poc/ <p>Remote, unauthenticated attackers could exploit the bugs to cause a denial-of-service (DoS) condition. The post Cisco Warns of High-Severity ClamAV Vulnerabilities With Public PoC appeared first on SecurityWeek .</p><p><strong>Source:</strong> SecurityWeek</p><p><strong>Tags:</strong> Vulnerabilities, Cisco, ClamAV, DoS, Patch, PoC, public PoC, vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also cyber_attacks 0.35)</p> 6d33e550407f92125e9575937f539db4 Vulnerabilities Cisco ClamAV DoS Patch PoC public PoC vulnerability bucket:vulnerabilities bucket:cyber_attacks Mon, 10 Aug 2026 14:07:48 +0000 https://access.redhat.com/hydra/rest/securitydata/csaf/RHSA-2026:52848.json <p>Red Hat security advisory RHSA-2026:52848. Severity: important. Addresses CVE-2026-49261.</p><p><strong>Source:</strong> Red Hat Security Advisories</p><p><strong>Tags:</strong> Security Advisory, Vulnerability, Red Hat, important, CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00; also threat_intel 0.68)</p> 86b97b6d6163a01ebf79fde51c89a87a Security Advisory Vulnerability Red Hat important CVE bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 14:06:03 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21380 <p>Updated the build numbers. This is an informational update only.</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> fa3aa937214ffe1662c1a764064af39d CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50309 <p>Updated an acknowledgement. This is an informational change only.</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 11d25163791faeaba3577b761083412a CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50357 <p>Acknowledgement Updated</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.96)</p> ea84f17872bbb765d16ab3949f0b8dbc CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-40417 <p>Updated the build numbers. This is an informational update only.</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.96)</p> 70a0010c40d6834540339b724e6837fe CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-29821 <p>Updated the build numbers. This is an informational update only.</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 523732ac3d3152e3e04d1378b38b2832 CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34474 <p>Updated the build numbers. This is an informational update only.</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 75318a2c3b13c3f776e6a299b11f1aa6 CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40440 <p>Updated the build numbers. This is an informational update only.</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.96)</p> 3970886ee538f614ad128f6d3e06075f CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38225 <p>Updated the build numbers. This is an informational update only.</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.96)</p> 484ec81b5608493af8f9fcdcb07588dd CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36946 <p>Updated the build numbers. This is an informational update only.</p><p><strong>Source:</strong> Microsoft Security Update Guide</p><p><strong>Tags:</strong> CVE</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.96)</p> b2e994123b63c71ab6b94d09df8b3423 CVE bucket:vulnerabilities Mon, 10 Aug 2026 14:00:00 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68355 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 274dc7581bbd3063381ce6e2da834e91 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:27 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68354 <p>In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment&#x27;s far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> c9ed490a05e82ff16981ad1233e5ef44 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:27 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68353 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 535f5ba6f46db56da45ef9ab16a28f8c CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:27 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68352 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi-&gt;is_wmm_enabled. Add a check that the total IE length fits within the buffer.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 3cb55554e3365a05a113f768ebf8696f CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:27 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68351 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar-&gt;readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar-&gt;readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar-&gt;readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> c893a69b3613e93087b859f7b3c4f1ca CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:27 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68350 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i &gt; ((cmd-&gt;hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i &gt;= (cmd-&gt;hdr.len / 2)`.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 21bdd2df18f5fcde570f42fda296c992 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:26 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68349 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> 8e849a36affd3c140600af41ab32e071 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:26 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68348 <p>In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 0ec03ead0f64d4d3ce0177af5da5ecf6 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:26 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68347 <p>In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -&gt; HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&amp;xa-&gt;xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&amp;domain-&gt;lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&amp;domain-&gt;lock){-.-.}-{3:3} -&gt; (&amp;xa-&gt;xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&amp;domain-&gt;lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 87e41d5d6ba31bb215db1fd59477ecf5 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:26 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68346 <p>In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret-&gt;buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 73329f86d622bb9d8cda99e050022c83 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:25 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68345 <p>In the Linux kernel, the following vulnerability has been resolved: arm_mpam: guard MBWU state before adding it to garbage __destroy_component_cfg() adds each RIS mbwu_state object to the MPAM garbage list when destroying component configuration. However, mbwu_state is allocated per RIS and only for RISes with MBWU monitors. A component can therefore have comp-&gt;cfg allocated while some RISes still have ris-&gt;mbwu_state set to NULL. Passing a NULL mbwu_state to add_to_garbage() dereferences the NULL pointer inside the macro. Skip RISes that do not have an mbwu_state object before adding them to the garbage list.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> b8dc811569c39b565ac2d757a3f84565 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:25 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68344 <p>In the Linux kernel, the following vulnerability has been resolved: usb: atm: ueagle-atm: reject descriptors that confuse probe and disconnect uea_probe() distinguishes a pre-firmware device from a post-firmware one using the USB id (UEA_IS_PREFIRM()), and stores a different object as the interface data in each case: a &#x27;struct completion&#x27; for a pre-firmware device (to be waited on in .disconnect()), or a &#x27;struct usbatm_data&#x27; for a post-firmware one. uea_disconnect() instead tells the two apart by the number of interfaces of the active configuration (a pre-firmware device exposes a single interface, ADI930 has 2 and eagle has 3), and casts the interface data accordingly. Because the two handlers use different criteria, a crafted device that advertises a pre-firmware id together with a multi-interface descriptor (or a post-firmware id with a single interface) makes them disagree: the small &#x27;struct completion&#x27; stored by uea_probe() is then passed to usbatm_usb_disconnect(), which casts it to &#x27;struct usbatm_data&#x27; and takes instance-&gt;serialize, reading past the end of the allocation: BUG: KASAN: slab-out-of-bounds in __mutex_lock+0x152a/0x1b80 Read of size 8 at addr ffff8880470</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> aef9d36af12b61d070b7b41ade110baa CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:24 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68343 <p>In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 3ddcab391d1ca4c8f9c7c9ae9d9c25d3 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:24 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68342 <p>In the Linux kernel, the following vulnerability has been resolved: ovpn: avoid putting unrelated P2P peer on socket release ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn-&gt;peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn-&gt;peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed </p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 570ff7e1cd075a86e70d93cd0773d288 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:24 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68341 <p>In the Linux kernel, the following vulnerability has been resolved: ovpn: fix use after free in unlock_ovpn() unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer-&gt;release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> 5f2f0cf11343e6fa87029d71f07442bf CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:24 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68340 <p>In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> ee15cc9cabf27206a2f9e3848b9b29ca CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:24 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68339 <p>In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> f991ac81b265ef9095e2abd6be47488e CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:24 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68338 <p>In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po-&gt;num, unregisters the protocol hook when needed, drops po-&gt;bind_lock, and later restores po-&gt;num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po-&gt;ifindex to -1 and clearing po-&gt;prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po-&gt;ifindex == -1 as an invalidated binding after reacquiring po-&gt;bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po-&gt;num as before, but do not </p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 755da28f7e590c765248081d9a07cba9 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:24 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68337 <p>In the Linux kernel, the following vulnerability has been resolved: bpf: Reject redirect helpers without a bpf_net_context The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current-&gt;bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways: * It calls bpf_redirect() directly, which dereferences the context at the top of the helper: tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \ avpkt 1000 burst 100 qevent early_drop block 10 tc filter add block 10 pref 1 bpf obj redirect.o * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle() then dispatches to skb_do_redirect(), which dereferences the context Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redi</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 670f3b04fd5a14eb364355175a74f9a7 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:24 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68336 <p>In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the &#x27;ipv6.disable=1&#x27; parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net-&gt;ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: &lt;TASK&gt; ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 34c789d568ff0f511fdeb294fde89272 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68335 <p>In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc-&gt;i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -&gt; rds_loop_kill_conns() -&gt; rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc-&gt;i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc-&gt;i_conn-&gt;c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc-&gt;i_conn-&gt;c_trans-&gt;inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-obj</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> a449484434ef94da87efc3ca05736c0f CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68334 <p>In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix io_thread race in rxrpc_wake_up_io_thread() rxrpc_wake_up_io_thread() checks local-&gt;io_thread before waking it, but then reloads the pointer for wake_up_process(). local-&gt;io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 59ec7fa333260decd06b0773130b64c1 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68333 <p>In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac-&gt;mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac-&gt;mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 1356e22847967646c0432e309e57c0d3 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68332 <p>In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix potential use-after-free in airoha_ppe_deinit() airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 (&quot;net: airoha: Fix schedule while atomic in airoha_ppe_deinit()&quot;) omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> d17a5ed91aded4aea201b7e34389725f CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68331 <p>In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac-&gt;mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac-&gt;mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 419548b72ea2767c7b53f45cf87eda8e CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68330 <p>In the Linux kernel, the following vulnerability has been resolved: net: airoha: Fix DMA direction for NPU mailbox buffer airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> bd9187798021868b059e683a596873de CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68329 <p>In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the &quot;block until all previously queued commands have completed&quot; contract in a multi-CPU scenario: CPU2: queue inv-B =&gt; need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false =&gt; return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> f14df87faf35aec31bfc9d2822cd6b5d CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68328 <p>In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 422b56613c3a4551a4f7305aefcb154d CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:23 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68327 <p>In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card-&gt;plx. On those early failures card-&gt;plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 2ecd9b4dbc8071f166db24aca2bc7018 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:22 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68326 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: sinfo-&gt;assoc_req_ies = &amp;event-&gt;data[len]; len = (u8 *)sinfo-&gt;assoc_req_ies - (u8 *)&amp;event-&gt;frame_control; sinfo-&gt;assoc_req_ies_len = le16_to_cpu(event-&gt;len) - (u16)len; event-&gt;len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter-&gt;event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()&#x27;d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event-&gt;len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event-&gt;len smaller than the header instead makes the int subtraction negative, which </p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 6f69ac8b23b80a9a155f4e2da4228487 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:22 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68325 <p>In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 2b697cf2fd044ea5affa11afc5c0b58a CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:22 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68324 <p>In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &amp;lstat[type]. When type &gt; 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 5f3ce3d18324d2f34b8afea74508bdcc CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:22 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68323 <p>In the Linux kernel, the following vulnerability has been resolved: tipc: serialize udp bearer replicast list updates tipc_udp_rcast_add() and cleanup_bearer() both update ub-&gt;rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list: list_del corruption. prev-&gt;next should be ffff8880298d7ab8, but was ffff88802449ad38. (prev=ffff888027e3ec98) kernel BUG at lib/list_debug.c:62! RIP: __list_del_entry_valid_or_report+0x17a/0x200 Workqueue: events cleanup_bearer Call Trace: cleanup_bearer (net/tipc/udp_media.c:811) process_one_work (kernel/workqueue.c:3302) worker_thread (kernel/workqueue.c:3466) The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM. Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list. Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> c9609060dda0a7e8b99c3ef2cb835a9d CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:22 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68322 <p>In the Linux kernel, the following vulnerability has been resolved: rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled When booting with the &#x27;ipv6.disable=1&#x27; parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags() KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: &lt;TASK&gt; ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp] rds_trans_get_preferred+0x15d/0x2d0 [rds] ? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds] ? rds_remove_bound+0xd50/0xd50 [rds] ? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 &lt;/TASK&gt; The following code reproduces the issue: struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPA</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> c1708f116b95980537051e91dcc6e237 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:22 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68321 <p>In the Linux kernel, the following vulnerability has been resolved: net: txgbe: fix FDIR filter leak on remove Perfect FDIR filters can be added while the interface is down and are kept on the software list for later restore. unregister_netdev() only calls ndo_stop when the device is up, so txgbe_fdir_filter_exit() in txgbe_close() is skipped in that case and the filters are leaked on driver remove. Free the filter list from txgbe_remove() as well.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 4746da78bb16a08c081404bbed6b3c3a CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:22 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68320 <p>In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep-&gt;auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc-&gt;c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 7770eb73524e4cdd5ecacac6ea73b482 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:22 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68319 <p>In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 86251217ec218ea46336a334ab78f5ae CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:21 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68318 <p>In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -&gt; pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue&#x27;s work and only then clear qcq-&gt;intx, so pdsc_process_adminq()&#x27;s read of qcq-&gt;intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> 3945bd8372ef8782ab1d5fed391e0d39 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:21 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68317 <p>In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf-&gt;vfs[vf_id].padev): a VF&#x27;s pdsc_reset_done() and the PF&#x27;s devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 89f2f0da27b5fd7f05bcafe2a8b22dbc CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:21 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68316 <p>In the Linux kernel, the following vulnerability has been resolved: accel: ethosu: Fix element size accounting for cmd stream validation There are 2 issues with the element size handling in the command stream validation which result in too small of a size calculated when the element size is 16/32/64 bits. For NHWC format, the element size is simply missing from the calculation. The bitfield for the element size is different between IFM/IFM2 and OFM. IFM and IFM2 encode the precision in parameter bits 2:3, while OFM uses bits 1:2.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> d0de419d096266b1f40bb3010683dc04 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:21 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68315 <p>In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU &gt; 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset requ</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 49d297d6e14c72e8db00135f3ac5e438 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:21 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68314 <p>In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> eeefb7e2c1de50a48da7d532985d2ca4 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:21 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68313 <p>In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd-&gt;dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit&#x27;s return value, propagate it and jump to err_out on error.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> df03a6e3ddb86d61d0a9436bfd55ba8e CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:21 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68312 <p>In the Linux kernel, the following vulnerability has been resolved: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing. The cifsFileInfo reference and the open server handle both leak. Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock. Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 2af75254569176bbf08873ed1cbb32cf CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:21 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68311 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: guard link STA in decap offload mt7925_sta_set_decap_offload() iterates over the vif valid_links mask when updating decap offload state for an MLO station. The station may not have a link STA for every valid link of the vif, so mt792x_sta_to_link() can return NULL for a link that belongs to the vif but not to the station. The function currently dereferences mlink before checking whether the link WCID is ready. If mlink is NULL, setting or clearing MT_WCID_FLAG_HDR_TRANS dereferences a NULL pointer. Skip links without a station link before touching mlink-&gt;wcid.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 702f536f977ddef96881bad9b4a8fcc9 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:20 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68310 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 76aee95734bca4c50f94d3b52b74f30c CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:20 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68309 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 74ecd8ca3baff3127fe81e9cb44ee8db CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:20 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68308 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 5158055d7b1de557051f7202dc138f90 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:20 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68307 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix crash in reset link replay During reset recovery, mt7925_vif_connect_iter() replays firmware state for links tracked in mvif-&gt;valid_links. After MLO link changes or MCU timeout recovery, the driver bitmap can temporarily contain a link whose mac80211 bss_conf has already gone away. This can pass a NULL bss_conf to mt76_connac_mcu_uni_add_dev(), matching the crash where x1, the second argument, is NULL: pc : mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] lr : mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] x2 : ffffff80a77f6018 x1 : 0000000000000000 x0 : ffffff8099402080 Call trace: mt76_connac_mcu_uni_add_dev+0x8c/0x1f8 [mt76_connac_lib] mt7925_vif_connect_iter+0x9c/0x168 [mt7925_common] mt7925_mac_reset_work+0x264/0x2f8 [mt7925_common] Skip missing bss_conf entries before replaying the link. Non-MLO AP/STA reset replay is unchanged because the helper still returns &amp;vif-&gt;bss_conf for the legacy link.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> c48173d4343455834766fe6ed4b01064 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:20 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68306 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> aacee116a85f16683d5fec96b0f851e0 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:20 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68305 <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Add drm_dev guards when detaching CCS read/write buffers CCS read/write buffers are freed during BO destruction. In some cases, BOs may be destroyed after the device is unbound but while the DRM structure remains valid, leading to NULL pointer dereferences when accessing device resources. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 9376 Comm: xe_pat Not tainted 7.2.0-rc2+ #1 PREEMPT(lazy) RIP: 0010:xe_sriov_vf_ccs_rw_update_bb_addr+0x4d/0xa0 [xe] RSP: 0018:ffffcf304110b9c8 EFLAGS: 00010246 RAX: ffff8a85c38a0a00 RBX: 00000000810ef000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8a85c39c1888 RBP: ffffcf304110b9e8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a85c39c1888 R13: 0000000000000000 R14: ffff8a85c39b4f28 R15: ffff8a85c3885000 FS: 0000000000000000(0000) GS:ffff8a878b809000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010314a002 CR4: 0000000000772ef0 PKRU: 55555554 Ca</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> a141217c844bd33367809a547ba60b80 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:20 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68304 <p>In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up &quot;use_fwsup&quot; with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]  &lt;TASK&gt; [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.83</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> da5c2081d33665a8ab51edc55e8ced02 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:20 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68303 <p>In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hvs/v3d: Fix null dereference in unbind The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error. Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 1b58c32f2873b86b84a2f5d2a98b9034 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68302 <p>In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph-&gt;saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() an</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 6a7369558911f4d94e6d79082e30c712 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68301 <p>In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port-&gt;dev, master-&gt;dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> afb6e8c4113404377a53dd6c21eca89f CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68300 <p>In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk-&gt;auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 6bc305ef10389666bfa142834db5398e CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68299 <p>In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc-&gt;rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4-&gt;protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth-&gt;h_proto != ...), when the tunnel&#x27;s outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 092db38f9973825241a7e618629e7c0c CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68298 <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix SVM leak on resv obj alloc failure in xe_vm_create() Commit 9e9787414882 (&quot;drm/xe/userptr: replace xe_hmm with gpusvm&quot;) made xe_svm_init() unconditional in xe_vm_create() and extended it to also initialize a &quot;simple&quot; gpusvm state for non-fault-mode VMs. The matching xe_svm_fini() call in xe_vm_close_and_put() was updated to run unconditionally, but the error unwind path in xe_vm_create() was not. On the drm_gpuvm_resv_object_alloc() failure path, xe_svm_init() has already succeeded but xe_svm_fini() is only called when XE_VM_FLAG_FAULT_MODE is set. For non-fault-mode VMs this leaves vm-&gt;svm.gpusvm partially initialized and leaks the resources allocated by drm_gpusvm_init(). For fault-mode VMs, xe_svm_init() additionally acquires the pagemap owner via drm_pagemap_acquire_owner() and the pagemaps via xe_svm_get_pagemaps(). Those resources are released by xe_svm_close(), not xe_svm_fini(). On the same error path, xe_svm_close() is not called either, so fault-mode VMs leak the pagemap owner and pagemaps. Fix both leaks: - Call xe_svm_fini() unconditionally on the err_svm_fini path, matching the u</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> f677e6812400edb29c05ec426adb971a CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68297 <p>In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l-&gt;mtu and l-&gt;advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l-&gt;mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tip</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 316f95b7cf38b09f31faa423db336045 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68296 <p>In the Linux kernel, the following vulnerability has been resolved: net: gre: fix lltx regression for GRE tunnels with SEQ/CSUM Before commit 00d066a4d4ed (&quot;netdev_features: convert NETIF_F_LLTX to dev-&gt;lltx&quot;), NETIF_F_LLTX was set unconditionally in both __gre_tunnel_init() and ip6gre_tnl_init_features() alongside GRE_FEATURES: dev-&gt;features |= GRE_FEATURES | NETIF_F_LLTX; When that commit converted NETIF_F_LLTX to the dev-&gt;lltx flag, it placed &#x27;dev-&gt;lltx = true&#x27; after the SEQ/CSUM early returns instead of before them. This causes GRE/GRETAP/ip6gre tunnels with SEQ or CSUM+encap to lose lockless TX, reintroducing _xmit_lock acquisition around their ndo_start_xmit. Since GRE xmit re-enters the stack via ip_tunnel_xmit(), holding _xmit_lock risks ABBA deadlock with the underlay device. CPU0 CPU1 ---- ---- lock(&amp;qdisc_xmit_lock_key#6); lock(&amp;qdisc_xmit_lock_key#3); lock(&amp;qdisc_xmit_lock_key#6); lock(&amp;qdisc_xmit_lock_key#3); Fix by moving dev-&gt;lltx = true before the early returns in both functions, restoring the original unconditional behavior.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 3be9b83a4bd2832eeca294eda7ca5e47 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:19 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68295 <p>In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Zero-extend signed ALU32 div/mod results ALU32 operations write a 32-bit result and leave the upper 32 bits of the BPF register zero. The LoongArch JIT sign-extends the result of signed ALU32 BPF_DIV and BPF_MOD (off=1), so a negative 32-bit quotient or remainder leaves bits 63:32 set in JITted code while the verifier and interpreter model those bits as zero. Keep sign-extension on the operands, which signed divide needs, and zero-extend the ALU32 result after the divide or modulo instruction, matching the unsigned ALU32 div/mod paths and every other ALU32 operation in this JIT.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> ae8ee6e6ad76d9f1a02bb96dadb82943 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68294 <p>In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates it</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 02b363fd5baa7e210d9b5e191c6e67a6 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68293 <p>In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the &#x27;out&#x27; buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> d7764cf7221a4c2a853a4ecf80fdb653 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68292 <p>In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf-&gt;txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf-&gt;txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI&#x27;s Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf-&gt;txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI&#x27;s ETF queue, not the CTRL VSI&#x27;s. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF V</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 8e5189064c566db543ddbba0b76b8866 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68291 <p>In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter-&gt;max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -&gt; 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed &lt;48&gt; 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 </p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> c8b8758e006175faa13834f5b6d39aa5 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68290 <p>In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn-&gt;rds_tcp_listen_sock-&gt;sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 1287ce251991033e9ecb539052a86afa CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68289 <p>In the Linux kernel, the following vulnerability has been resolved: tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream() In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always &lt;= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> d41b5fad903925184ac0536e29cf2afd CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68288 <p>In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 0d062e2625befc40e9eed9322218d311 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68287 <p>In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix size calculations for 64-bit attributes net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 944f52491e600f6c04516741d46af9cd CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:18 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68286 <p>In the Linux kernel, the following vulnerability has been resolved: drop_monitor: perform u64_stats updates under IRQ-disabled section In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&amp;...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> e55ffc70037ac89911d7efc69b37b420 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:17 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68285 <p>In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Fix memory leak in bpf_jit_free() When bpf_int_jit_compile() is called for subprograms, it returns early during the first pass (!prog-&gt;is_func || extra_pass is false), keeping ctx-&gt;offset alive for the subsequent extra pass. If JIT compilation fails for a later subprogram, the BPF core aborts and calls bpf_jit_free() to clean up the first subprogram. However, bpf_jit_free() fails to free jit_data-&gt;ctx.offset, which causes a memory leak of the JIT context offsets array. So fix this by adding the missing kvfree(jit_data-&gt;ctx.offset) in bpf_jit_free().</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 22ee37a4218b084e78968df6b1e9713a CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:17 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68284 <p>In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock-&gt;cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock-&gt;cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock-&gt;cork = NULL frees the cork reacquires the socket lock msg_tx != psock-&gt;cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> ee78944d7adae02c109e6e18c9979c6f CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:17 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68283 <p>In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c (&quot;tracing: Add bulk garbage collection of freeing event_trigger_data&quot;) moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()&#x27;d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correc</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> 0c4cf851329e9979cd8f7f1c1fceb655 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:17 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68282 <p>In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: analogix_dp: Add missing error check for platform_get_resource() Add missing error check for platform_get_resource() return value to prevent NULL pointer dereference when memory resource is not available.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 88eada62301d185a4d2a9fd98a01cb89 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:17 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68281 <p>In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler&#x27;s prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue&#x27;s CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can&#x27;t be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (dep</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 82d78e3825085083a25ccaf147c63b5c CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:17 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68280 <p>In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Brid</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> eca5d93d7ac5c6b11fbc2feef935dfd3 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:17 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68279 <p>In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &amp;raw-&gt;msg[idx], num_bytes); without checking that idx + num_bytes &lt;= raw-&gt;curlen. raw-&gt;msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw-&gt;msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes &gt; curlen) before each memcpy. Since num_bytes is u8, it is always &gt;= 0, so this strictly subsumes the simpler idx &gt; curlen form and no separate step is needed. [added missing fixes tag]</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 835632ef08122ccb21a0241ce806d14a CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:17 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68278 <p>In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx &gt;= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply m</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> b1ede42af146613ccc22b0ee41d2406e CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:16 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68277 <p>In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw-&gt;msg[idx] &lt;&lt; 8) | (raw-&gt;msg[idx+1]); and check bounds only after the fact. When idx == raw-&gt;curlen, raw-&gt;msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 &gt; curlen) before each 2-byte read. Since the check is strictly tighter than idx &gt; curlen, no separate step is needed. [added fixes tag]</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> cdb0f10a53235e7041fbbf84b83f037d CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:16 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68276 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx: fix cleaner shader IB buffer overflow The cleaner shader sysfs path allocates a 16-dword (64 byte) IB but incorrectly fills (align_mask + 1) dwords. On GFX rings align_mask is 0xff, so the loop wrote 256 dwords into a 64-byte buffer, causing a kernel page fault. The IB only needs to be a minimal NOP shell to schedule the job; the cleaner shader itself is emitted on the ring via emit_cleaner_shader(). Fill 16 dwords to match the allocation. v2: Use ib_size_dw variable (Lijo) (cherry picked from commit bf21af331ebf72d0935fd70c73192414a422c03a)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 5e60e8b99d235abb31044d4af53fc227 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:16 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68275 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: check amdgpu_vm_bo_find() result in GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO path of amdgpu_gem_op_ioctl() looks up the bo_va for the buffer object in the caller&#x27;s VM via amdgpu_vm_bo_find(), but uses the returned pointer without checking it. amdgpu_vm_bo_find() returns NULL when the BO has no bo_va in that VM, which is the normal case for a BO that has never been mapped. The result is fed straight into amdgpu_vm_bo_va_for_each_valid_mapping(), which expands to list_for_each_entry(mapping, &amp;(bo_va)-&gt;valids, list) and dereferences bo_va, causing a NULL pointer dereference. This is reachable by any process able to issue the ioctl (render group) simply by requesting mapping info for an unmapped BO. Return -ENOENT when no bo_va is found, jumping to out_exec so the drm_exec context and GEM object reference are released. (cherry picked from commit 528b19377affc1cc7362a70a254c1dda793595f9)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98; also threat_intel 0.53)</p> 64bd04a75c9bd650aa1b7bd7562ed480 CVE Vulnerability bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 13:20:16 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68274 <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt-&gt;fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 1.00)</p> c2de94d48bf7ff0476b35b21a1429dc1 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:16 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68273 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix context pstate override handling There are several problems in the context pstate handling code. The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev-&gt;pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer. Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx-&gt;stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested. The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock. Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on c</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 55064963c13f29742e63ea2ff429fca9 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:16 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68272 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk-&gt;kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow-&gt;flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 9b1daf3e98e3e10027b4b9d6ae228f12 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:16 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68271 <p>In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args-&gt;in_sync.s. Since args-&gt;in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 93b27383a3455607eff9aeb2dc70e718 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:16 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68270 <p>In the Linux kernel, the following vulnerability has been resolved: drm/sysfb: Avoid possible truncation with calculating visible size Calculating the visible size of the system framebuffer can result in truncation of the result. The calculation uses 32-bit arithmetics, which can overflow if the values for height and stride are large. Fix the issue by multiplying with mul_u32_u32().</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 268f016193808bdc094c6aa09107b065 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:15 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68269 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 01f882b7757ab7bc8295330fd17f4238 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:15 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68268 <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe: Return error on non-migratable faults requiring devmem Non-migratable faults that require devmem incorrectly jump to the &#x27;out&#x27; label, which squashes the error code intended to be returned to the upper layers. Fix this by returning -EACCES instead. (cherry picked from commit c4508edb2c723de93717272488ea65b165637eac)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 904ac555d0294b23a75bb05a337834bb CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:15 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68267 <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe/rtp: Add RING_FORCE_TO_NONPRIV_DENY to OA whitelists Unconditionally whitelisting OA registers is a security violation. Set RING_FORCE_TO_NONPRIV_DENY bit in OA nonpriv slots, so that OA registers don&#x27;t get whitelisted by default after probe, gt reset, resume and engine reset. (cherry picked from commit 90511bdcfda97211c01f1d945d4ea616578d8fca)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 7d6847f7cc488b1baffddb78a01df965 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:15 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68266 <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter&#x27;s dma_buf-&gt;resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo-&gt;base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo-&gt;base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destr</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 686c1d59e52588077f8154a1cd727451 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:15 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68265 <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: Fix BO prefetch with CONSULT_MEM_ADVISE_PREF_LOC When prefetch region is DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC for a BO VMA, the code used it as an index into region_to_mem_type[], causing an out-of-bounds access since the value is -1. Resolve the preferred location for BO VMAs directly: local VRAM on dGFX (using the BO&#x27;s tile placement) or system memory on iGPU. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: -Fix null dereference (cherry picked from commit d9a4906ac03be9f6ed3f3b45c56c866b867fd75b)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> fc3e847e90a196d575465229cc1d9323 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:15 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68264 <p>In the Linux kernel, the following vulnerability has been resolved: drm/xe/pt: Reset current_op in xe_pt_update_ops_init() xe_pt_update_ops_init() fails to reset current_op to 0. On the vm_bind path, ops_execute() calls xe_pt_update_ops_prepare() inside the xe_validation_guard() / drm_exec_until_all_locked() loop. When that loop retries due to lock contention or OOM eviction (drm_exec_retry_on_contention() / xe_validation_retry_on_oom()), xe_pt_update_ops_prepare() runs again on the same vops, and each call to bind_op_prepare() increments current_op without resetting it. After N retries current_op exceeds the array size allocated by xe_vma_ops_alloc(), causing an out-of-bounds write into SLUB-poisoned memory and a subsequent UAF crash in xe_migrate_update_pgtables_cpu() when reading the corrupted pt_op-&gt;bind. Also reset needs_svm_lock and needs_invalidation which are derived in the same prepare pass and would otherwise cause wrong migrate ops selection and redundant TLB invalidation on retry. Fix this by resetting current_op, needs_svm_lock and needs_invalidation in xe_pt_update_ops_init(). v2 (Matt): - Add details in commit message. - Add Fixes tag and Cc to stable@vge</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 1064e7c5a7cbc760d75e3c07abacfbaf CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:15 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68263 <p>In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (&quot;drm/sched: Account entity GPU time&quot;): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CP</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 8e0ca8f13e12dd27d6fa8bf122737316 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:15 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68262 <p>In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out-&gt;stride. When out-&gt;stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out-&gt;stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 7c13949aa78fb47e2f29be0416ed0ac3 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:14 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68261 <p>In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 000000009600000</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98; also threat_intel 0.59)</p> a0cbada829eb809a20a434e3a314dc55 CVE Vulnerability bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 13:20:14 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68260 <p>In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx-&gt;lock before mapping memory to GPU VM The drm gpuvm code doesn&#x27;t protect find operation against map operation, and the driver needs to ensure a map operation shouldn&#x27;t happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [&lt;ffffffff01e989d4&gt;] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [&lt;ffffffff01ed3a40&gt;] pvr_vm_unmap+0x34/0x68 [powervr] [&lt;ffffffff01ec69da&gt;] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [&lt;ffffffff8080ce0a&gt;] drm_ioctl_kernel+0x8e/0xdc [&lt;ffffffff8080d016&gt;] drm_ioctl+0x1be/0x3e0 [&lt;ffffffff802bec3e&gt;] __riscv_sys_ioctl+0xba/0xc4 [&lt;ffffffff80d858b2&gt;] do_trap_ecall_u+0x23e/0x3f4 [&lt;ffffffff80d92288&gt;] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx-&gt;lock, make pvr_vm_map() to acquire this lock to prevent disturbing any</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97; also threat_intel 0.53)</p> 4a4a2447dd4e8d1d5e91abfe1c86d97f CVE Vulnerability bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 13:20:14 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68259 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren&#x27;t checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 5048f9497096c21b724c8f0f40b3c81f CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:14 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68258 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds on CRIU restore queue type and mqd size We weren&#x27;t checking whether the values provided in the private data in kfd CRIU restore were within bounds. For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it. For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations. (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 98005d50df01a453876b29564195a15d CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:14 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68257 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix 32-bit overflow in CWSR total size calculation total_cwsr_size was computed in 32-bit before being used as a BO/SVM allocation size. With large ctx_save_restore_area_size and debug_memory_size multiplied by the XCC count, the product can wrap, yielding an undersized CWSR save area that firmware later overruns. Promote total_cwsr_size to u64 and use check_add_overflow()/ check_mul_overflow() in both kfd_queue_acquire_buffers() and kfd_queue_release_buffers(). (cherry picked from commit 319f7e13423ae3f486b9aea82f9ad2d6af0ee608)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 8ded829aa34141d848d4e811a3e36db5 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:14 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68256 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 6749067276e5c4589484dfd9e06f9dce CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:14 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68255 <p>In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp-&gt;size field, never against the fixed-size resp-&gt;edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 264bd990340e8fc3730e676f898e61cc CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:14 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68254 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/vrr: require valid min/max vfreq for VRR Ensure the EDID provided min/max vfreq are valid. Most scenarios are already covered (by coincidence) through the checks in intel_vrr_is_capable() and intel_vrr_is_in_range(), but be more explicit about it. At worst, a zero min_vfreq could lead to a division by zero in intel_vrr_compute_vmax(). Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 1765cf59f517b02f3b0591fe5120930d08bddeb6)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 02565c60889d36ee24e1d74684599f2d CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68253 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: check streams[] bounds before overflow The data-&gt;streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> b1985f2922a6235eacbbc15aef9b6d1c CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68252 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma7.0: replace BUG_ON() with WARN_ON() There&#x27;s no need to crash the kernel for these cases. (cherry picked from commit 9723a8bed3aa251a26bee4583bac9d8fb064dd44)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> c09329172ba5d8c94c6c64086ed83030 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68251 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There&#x27;s no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> e4724d5fd94ebb18d72ce5487b02ff9d CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68250 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There&#x27;s no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> dfaa8509116ea81238b0556e6dd669d8 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68249 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There&#x27;s no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> b54e9268672a440aba27335d7610b1ba CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68248 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &amp;node-&gt;base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> 1ee928bfcfd6cf0be258548336a6486a CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68247 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 1da4c029208cc3d6c5cd0856df1d4bb7 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68246 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There&#x27;s no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> c98814cffe93b754c82100ea393459f0 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:13 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68245 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid() The vm pointer returned from amdgpu_vm_get_vm_from_pasid() is only valid while the lock is still being held. Once xa_unlock_irqrestore is called and returned, the pointer is no longer under lock and is subject to modification. Since, the caller still dereferences vm-&gt;task_info in amdgpu_vm_get_task_info_vm() after the lock is removed, this causes a use after unlock problem. Remove the lifetime issue present in amdgpu_vm_get_task_info_pasid() through removing the amdgpu_vm_get_vm_from_pasid() function from amdgpu_vm.c and making the relevant code inline to hold the lock while it is still in use. (cherry picked from commit 9d01579f3f868b333acc901815972685989092c7)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 41240b61a43ef1968fe1cdef2b0b6fed CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68244 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 48502204aa964b8228cdf1c62abb3edc CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68243 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> e5f3e85019987a330193c8fb9a1e8968 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68242 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix NULL deref on sched_engine alloc failure Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98; also threat_intel 0.59)</p> eeb7bf375bfd8bbce2b0c8a236018e2a CVE Vulnerability bucket:vulnerabilities bucket:threat_intel Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68241 <p>In the Linux kernel, the following vulnerability has been resolved: drm/i915/mst: limit DP MST ESI service loop The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto. (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 68caece5145527f774a21530ed57af66 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68240 <p>In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: publish dpagemap early to avoid device mapping leak on error drm_gpusvm_get_pages() only stored the local dpagemap into svm_pages-&gt;dpagemap on the success path. If a later page failed (e.g. -EOPNOTSUPP when ctx-&gt;allow_mixed is false) and jumped to err_unmap, svm_pages-&gt;dpagemap was still NULL, so __drm_gpusvm_unmap_pages() skipped device_unmap() and leaked the device mappings already created. Assign svm_pages-&gt;dpagemap when the first device page is mapped so the err_unmap path can device_unmap() those mappings. This issue was found by Sashiko AI review.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> c8590eb0127ab89b868fc7561b4cad04 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68239 <p>In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Account for NULL and handle pages in ttm_pool_backup Pages in ttm_pool_backup can be NULL or backup handles (ttm_backup_page_ptr_is_handle()), neither of which can be passed to set_pages_array_wb() or freed. Add a dedicated WB pass before the dma/purge loop that walks allocations using the same i += num_pages stride, skipping NULL and handle entries, and calls set_pages_array_wb() once per contiguous run of real pages. Apply the same NULL/handle guard to the dma/purge loop. Fixes the following oops: Oops: general protection fault, kernel NULL pointer dereference 0x0: 0000 [#1] SMP NOPTI RIP: 0010:__cpa_process_fault+0xf8/0x770 RSP: 0018:ffffc90000a87718 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffffc90000a87868 RCX: 0000000000000000 RDX: 0000000000001000 RSI: 0005088000000000 RDI: ffffffff827c5f34 RBP: 0005088000000000 R08: ffffc90000a877cb R09: ffffc90000a877d0 R10: 0000000000000000 R11: 000000000000001b R12: 000ffffffffff000 R13: ffffc90000a87868 R14: ffffc90000a87868 R15: ffff88815b882ae0 FS: 0000000000000000(0000) GS:ffff8884ec840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: </p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 60bc64c0b655f1142ec20411666007e4 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68238 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Release VFCT ACPI table reference amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0-&gt;1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found. Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller. (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 8f81e5cbf82e9fc8696a7f5ef9a565aa CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68237 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: fix indefinite fence wait during GPU reset pre_reset only force-completes fences of MAPPED queues. A queue in any other state (e.g. mid-eviction) keeps its last_fence pending; after a GPU reset that fence never signals, so the eviction/suspend worker and process teardown (amdgpu_evf_mgr_flush_suspend) wait on it forever and wedge the machine: INFO: task kworker/6:28 blocked for more than 120 seconds. Workqueue: events amdgpu_eviction_fence_suspend_worker [amdgpu] Call Trace: dma_fence_wait_timeout+0x7e/0x130 amdgpu_userq_evict+0x67/0x140 [amdgpu] amdgpu_eviction_fence_suspend_worker+0xd8/0x160 [amdgpu] process_scheduled_works+0xa6/0x420 Force-complete every queue&#x27;s fence regardless of state. The unmap and mark-hung step stays gated on MAPPED, since unmapping a queue that is not mapped is invalid. (cherry picked from commit 9102b39fa924dcc3dc75a3137bfa9633c40b88c0)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 5d9f779b2b4098a24a8913313560d7cb CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:12 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68236 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.99)</p> 28e46834e01c6e1d1588a72b0ed44bcd CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:11 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68235 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream-&gt;signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 2</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 94177fefe2791b423018a2a755643e4d CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:11 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68234 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo-&gt;pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 463710ab6b1f33f6e12770e904dd8888 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:11 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68233 <p>In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Shut down BO cache timer before teardown The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old(). vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown. Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.97)</p> e6f307e8c56f2a02a42c67e17e7a8a7a CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:11 +0000 https://nvd.nist.gov/vuln/detail/CVE-2026-68232 <p>In the Linux kernel, the following vulnerability has been resolved: drm/gpusvm: Fix MM reference leak in drm_gpusvm_range_evict If kvmalloc_array() fails in drm_gpusvm_range_evict(), the MM reference acquired earlier is not released, resulting in a reference leak. Fix this by dropping the MM reference on the kvmalloc_array() failure path.</p><p><strong>Source:</strong> NIST NVD Recent CVEs</p><p><strong>Tags:</strong> CVE, Vulnerability</p><p><strong>Classification:</strong> vulnerabilities (confidence 0.98)</p> 2bb71f75225b6406df4c5b93644859a4 CVE Vulnerability bucket:vulnerabilities Mon, 10 Aug 2026 13:20:11 +0000