Bug 1220636 (CVE-2021-46946)

Summary: VUL-0: REJECTED: CVE-2021-46946: kernel: ext4: fix check to prevent false positive report of incorrect used inodes
Product: [Novell Products] SUSE Security Incidents Reporter: SMASH SMASH <smash_bz>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: RESOLVED INVALID QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: andrea.mattiazzo, rfrohl, vasant.karasulli
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://smash.suse.de/issue/395353/
Whiteboard: CVSSv3.1:SUSE:CVE-2021-46946:0.0:(AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:N)
Found By: Security Response Team Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description SMASH SMASH 2024-02-29 09:46:21 UTC 
In the Linux kernel, the following vulnerability has been resolved:

ext4: fix check to prevent false positive report of incorrect used inodes

Commit <50122847007> ("ext4: fix check to prevent initializing reserved
inodes") check the block group zero and prevent initializing reserved
inodes. But in some special cases, the reserved inode may not all belong
to the group zero, it may exist into the second group if we format
filesystem below.

  mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda

So, it will end up triggering a false positive report of a corrupted
file system. This patch fix it by avoid check reserved inodes if no free
inode blocks will be zeroed.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-46946
https://www.cve.org/CVERecord?id=CVE-2021-46946
https://bugzilla.redhat.com/show_bug.cgi?id=2266484
https://lore.kernel.org/linux-cve-announce/20240227184057.2368370-11-gregkh@linuxfoundation.org/T/#u

Patch:
https://git.kernel.org/stable/c/a149d2a5cabbf6507a7832a1c4fd2593c55fd450
Comment 1 Andrea Mattiazzo 2024-02-29 09:47:31 UTC 
Tracking as affected:
-cve/linux-4.12
-cve/linux-4.4
-cve/linux-3.0
Comment 4 Jan Kara 2024-03-07 16:45:42 UTC 
So this CVE report is completely pointless. TL;DR is: If you create a filesystem with absurd parameters, the kernel will (mistakenly) refuse to mount it. How is this possibly security relevant? IMO this is a clear dispute candidate.

But maybe we don't want to bother because commit 50122847007 landed in 4.18-rc7 and has Fixes tag to commit 8844618d8aa7 which landed in 4.18-rc4. cve/linux-4.12 has 8844618d8aa7 backported but 50122847007 is there as well. So I've just added CVE reference there and we are done.
Comment 7 Andrea Mattiazzo 2024-05-31 13:19:08 UTC 
Closing as invalid since rejected