Story of CVE-2024-26972: On January 6, 2024, commit: 1e022216dcd248326a5bb95609d12a6815bca4e2 ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path is merged in Linux by Richard Weinberger this fixes a real memory leak report in ubifs_symlink() On February 25, 2024, the same commit with the same description was merged a second time, but due to the diff context of the patch site being identical to another site in ubifs_mknod(), it was applied there instead (vs git claiming the commit was already applied and doing nothing instead). However, there was no vulnerability in ubifs_mknod(), and (luckily) the "fix" is a pure no-op, as can be seen in the definition of fscrypt_free_inode(): void fscrypt_free_inode(struct inode *inode) { if (IS_ENCRYPTED(inode) && S_ISLNK(inode->i_mode)) { kfree(inode->i_link); inode->i_link = NULL; } } Note that it operates only on symlinks, as would be the case in ubifs_symlink(), but not ubifs_mknod(). On May 1, 2024, the Linux CNA's automation produces CVE-2024-26972: https://lore.kernel.org/linux-cve-announce/2024050132-CVE-2024-26972-bf6c@gregkh/ The automation identifies only the 2nd commit from February 25th and a backport of that commit to the 6.8 stable kernel made by Sasha Levin (presumably derived from AUTOSEL) and committed by Greg KH on April 3 2024. So take note, at no time does the CVE actually identify the correct fix for the vulnerability, all references are to the bad no-op fix. On July 12, 2024, the following commit (authored April 10th, prior to the May CVE issuance) was merged by Richard Weinberger: 7bed61a1cf166b5c113047fc8f60ff22dcb04893 Author: Zhihao Cheng AuthorDate: Wed Apr 10 15:37:45 2024 +0800 Commit: Richard Weinberger CommitDate: Fri Jul 12 21:35:00 2024 +0200 Revert "ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path" This reverts commit 6379b44cdcd67f5f5d986b73953e99700591edfa. Commit 1e022216dcd2 ("ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path") is applied again in commit 6379b44cdcd6 ("ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path"), which changed ubifs_mknod (It won't become a real problem). Just revert it. Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Sometime in August, inferring from: https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec/-/blob/master/issues/CVE-2024-26972.yml?blame=1 Ubuntu noticed the CVE referred to the wrong fix. It does not appear from public publications that any other distro noticed any error with the CVE. On October 10th, from Vegard Nossum catching up on CVEs and trying to backport their fixes to upstream LTS kernels (as evidenced in the tags of commit b9077897329384b92435f9cafd7ee3c11a3eaa70): (cherry picked from commit 6379b44cdcd67f5f5d986b73953e99700591edfa) [Vegard: CVE-2024-26972; no conflicts] Signed-off-by: Vegard Nossum the bad fix was backported to the 6.6 LTS kernel. From the stable list, we can see this was submitted October 2nd: https://www.spinics.net/lists/stable-commits/msg377700.html from a group of other CVE-catchup backports submitted as RFC that same day: https://www.spinics.net/lists/stable/msg778740.html and accepted by Greg KH on October 8th: https://www.spinics.net/lists/stable-commits/msg377699.html But on October 4th, Sasha (who performed the original bad backport to 6.8) pointed out that the commit being backported was a duplicate: https://www.spinics.net/lists/stable/msg779328.html It's not clear, but either from Sasha's public mention or via private feedback on Greg's October 8th mail (via its CC list), Greg finally caught on to the problem. So, within the same release, merged with the bad commit (rather than simply dropping it from the queue), was the revert for that same commit, known since July: commit 3faea7810e2b3e9a9a92ef42d7e5feaeb8ff7133 Author: Zhihao Cheng AuthorDate: Wed Apr 10 15:37:45 2024 +0800 Commit: Greg Kroah-Hartman CommitDate: Thu Oct 10 11:58:09 2024 +0200 Revert "ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path" commit 7bed61a1cf166b5c113047fc8f60ff22dcb04893 upstream. This reverts commit 6379b44cdcd67f5f5d986b73953e99700591edfa. Commit 1e022216dcd2 ("ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path") is applied again in commit 6379b44cdcd6 ("ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path"), which changed ubifs_mknod (It won't become a real problem). Just revert it. Signed-off-by: Zhihao Cheng Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman The same day, the CVE record for CVE-2024-26972 was quietly updated, with no mail sent to linux-cve-announce. Rather than fully updating the references for the CVE to point to the actual vulnerability fix (which would allow for "Fixed in" versions for LTS kernels to be properly represented), presumably due to the CNA's automation, it simply added a reference to the new 6.6 revert commit, meaning the sum of references for the CVE only tell people to apply a non-fix for a real vulnerability, and then revert that non-fix. There is no reference to the actual fix from 9 months earlier in January, which had already been backported to stable kernels shortly after (for instance, b2512424c9c539a0024b4faeb5925990bd4302a0 for 5.15 on February 23rd). Garbage in, garbage out, and the Oct 10th backport attempt of a non-fix demonstrates people are operating on that garbage.