Hi Greg, Thank you for commenting on this.
On Thu, Apr 30, 2026 at 06:52:15PM +0200, Greg KH wrote: > On Thu, Apr 30, 2026 at 03:17:45AM -0400, cyber security wrote: > > That is very terrifying, is it is 10.0 score? > > There is a score in the CVE entry, does that not show up properly for > people somehow? It does. I guess someone top-posting a one-liner couldn't have bothered to check before posting or just wanted to share the emotions or provoke a discussion of CVSS scoring. Luckily, your reply actually adds value: > This was one of the few CVE ids that we have provided a score for, why > people ignored that is confusing. You should contact your distro if you > are paying for support to find out why this happened as it should have > been covered by your support contract. That's interesting perspective. I just went to see whether a distro vendor could reasonably use this as a signal to prioritize this CVE fix. Here's what I did (after looking with my eyes to see the pattern first): git clone https://git.kernel.org/pub/scm/linux/security/vulns.git cd vulns git log | grep -B3 'Add CVSS' | grep -c 'Apr 25 .* 2026' This says 168. That's how many CVEs your team (this time, Sasha Levin) kindly scored on Saturday, April 25. So ~4 days prior to this one CVE making the news, ~2 days of which were the weekend. This CVE got a CVSS score of 7.8. The rest of the 168 got scores from 7.1 to 9.8. By the score alone, this one really does not stand out. To me, this is usual noise, with little signal in there. Now, your team's message may be: distros can't possibly fix all kernel CVEs, not even those you provide high CVSS scores for, and especially not quickly enough, other than by staying with mainline or upstream stable/longterm kernels. Is this your actual and only message - not that distros should have magically seen the needle in the haystack? The scoring reasoning for this CVE does not hint at its severity and the threat being imminent. It's as obscure as most of the rest of 168 are (which for most of them is probably a result of actually not having exploitability and impact analysis). I understand not wanting to draw attention to a CVE that wasn't fully disclosed by the researchers yet, but you can't simultaneously say that _this_ was the heads-up to distros - it wasn't. Please don't get me wrong, I appreciate the extra effort your team is taking to process some kernel bugs as CVEs and even to score them. I understand that with so many, quality can't be perfect. It's just that instead of drowning in the CVE/CVSS noise, we need a high-quality signal for CVEs that matter the most. Things that would certainly have been CVEs even prior to Linux CNA setup. They may not score the highest per CVSS, but in many cases - like in this one - your team has the knowledge that an issue is to become high-profile, so a timely direct heads-up to linux-distros would be appreciated. Where by "timely" I mean, say, a week (and never more than 14 days) before planned full public disclosure. We don't normally like to sit on semi-embargoed issues with public fixes, but we did introduce an exception for "Linux kernel issues concurrently or very recently handled by the Linux kernel security team" specifically to accommodate the way your team works. How does this sound to you? Of course, I recognize that in this case the decision not to notify Linux distros is partially with the researchers. While the current instructions from both the kernel and linux-distros do make this somewhat discouraging and difficult for researchers (which is really unfortunate), the possibility is there. For linux-distros, we have: "For Linux kernel issues, you must notify the kernel security team first, wait for the fix, and only then notify linux-distros or oss-security (depending on whether the information is still private or already public, as well as on issue severity)." In this case, _some_ information was still private even when the fix was public, and severity could have justified special handling. Related to the above, I recall this recent experience and statement by Qualys (in context of another Linux kernel issue): https://www.openwall.com/lists/oss-security/2026/03/12/6 Specifically, this paragraph they wrote: > Although contacting the linux-distros list has been clearly beneficial > (they have thoroughly reviewed and tested the patches, and were able to > prepare their kernel updates beforehand), we have reached the conclusion > that it has become increasingly difficult to coordinate the disclosure > of kernel vulnerabilities with both groups (the Linux kernel security > team and the linux-distros list), because they have very different > policies. From now on, we will coordinate the disclosure of kernel > vulnerabilities with the Linux kernel security team only. We also > apologize in advance for this. With the researchers at Qualys feeling that way, I can't really blame other researchers for essentially doing the same as Qualys say they're going to start doing. While not blaming, I do feel there can still be cases where a carefully timed notification to linux-distros would work well. Thanks, Alexander Oh, and here's the vulns repo CVSS score commit for this CVE: commit cb9d133eed6ab823b8fdefdc10600189aa69a107 Author: Sasha Levin <[email protected]> Date: Sat Apr 25 07:35:42 2026 -0400 CVE-2026-31431: Add CVSS 3.1 score (7.8 HIGH) CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H AV:L -The vulnerable algif_aead path is reached through local AF_ALG socket syscalls: socket, bind, setsockopt, accept, sendmsg, and recvmsg. It is not directly reachable from remote network packets. AC:L -A local attacker can construct the AF_ALG AEAD request, choose buffer layout, AAD/tag lengths, and invoke recvmsg directly. Any race or SGL layout condition is attacker-controlled from the same process. PR:L -Creating and using AF_ALG AEAD sockets requires only an unprivileged local user on systems with CRYPTO_USER_API_AEAD enabled. The traced socket, bind, setsockopt, accept, sendmsg, and recvmsg paths do not require CAP_SYS_ADMIN or other real root privileges. UI:N -No victim interaction is needed once the attacker has local code execution. The attacker can open and drive the AF_ALG socket entirely through syscalls. S:U -The issue remains within the kernel/user crypto API security authority and does not cross a VM, IOMMU, or separate sandbox boundary. This is a standard local kernel attack surface. C:H -The removed in-place AEAD design used user-writable RX scatterlists as crypto source data and chained TX tag pages, creating a plausible decryption/authentication bypass for data protected by secret AEAD keys. Under the required uncertainty rule, this is scored as high confidentiality impact. I:H -The bug undermines AEAD authenticity by allowing source data used by the crypto operation to diverge from the data originally submitted and authenticated. This can allow forged or corrupted plaintext/ciphertext results, so integrity impact is high. A:H -The vulnerable path builds complex chained scatterlists from attacker-controlled local buffers and related AF_ALG fixes show these paths can lead to scatterwalk NULL dereferences and kernel panics. A local attacker can repeatedly trigger the operation, so availability impact is high. Signed-off-by: Sasha Levin <[email protected]>
