In the Linux kernel, the following vulnerability has been resolved: afs: Increase buffer size in afs_update_volume_status() The Linux kernel CVE team has assigned CVE-2024-26736 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040359-CVE-2024-26736-284d@gregkh/T
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2273277]
On 2024-04-03 CVE-2024-26736 was announced in response to the merging of commit 6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d Author: Daniil Dulov <d.dulov> Date: Mon Feb 19 14:39:03 2024 +0000 afs: Increase buffer size in afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()] Fixes: d2ddc776a458 ("afs: Overhaul volume and server record caching and fileserver rotation") Signed-off-by: Daniil Dulov <d.dulov> Signed-off-by: David Howells <dhowells> Link: https://lore.kernel.org/r/20240211150442.3416-1-d.dulov@aladdin.ru/ # v1 Link: https://lore.kernel.org/r/20240212083347.10742-1-d.dulov@aladdin.ru/ # v2 Link: https://lore.kernel.org/r/20240219143906.138346-3-dhowells@redhat.com Signed-off-by: Christian Brauner <brauner> After a careful examination of the change and the code history I believe the referenced "Fixes" commit is incorrect. It should be commit 3b6492df4153b8550d347dfc581856138678a231 Author: David Howells <dhowells> Date: Sat Oct 20 00:57:57 2018 +0100 afs: Increase to 64-bit volume ID and 96-bit vnode ID for YFS Increase the sizes of the volume ID to 64 bits and the vnode ID (inode number equivalent) to 96 bits to allow the support of YFS. This requires the iget comparator to check the vnode->fid rather than i_ino and i_generation as i_ino is not sufficiently capacious. It also requires this data to be placed into the vnode cache key for fscache. For the moment, just discard the top 32 bits of the vnode ID when returning it though stat. Signed-off-by: David Howells <dhowells> which was initially merged as part of v4.20-rc1 and not 4.15 as indicated by CVE-2024-26736. commit 3b6492df4153b8550d347dfc581856138678a231 increased the size of typedef afs_volid_t from "unsigned int" to "u64" without increasing the size of idbuf[] within afs_update_volume_status(). However, since the introduction of 3b6492df4153b8550d347dfc581856138678a231 there has yet to be any implementation of either RPC YFSVL_GetEntryByName64 or YFSVL_GetEntryByID64 which would permit a volume id larger than 32-bits to be stored into the struct afs_volume.vid afs_volid_t typed field. fs/afs uses the VL_GetEntryByNameU and VL_GetEntryByIDU RPC variants which only support 32-bit volume ids. Therefore, I do not believe that the code present in afs_update_volume_status() char idbuf[16]; idsz = sprintf(idbuf, "%llu", volume->vid); could in practice result in a buffer overflow as indicated by CVE-2024-26736 since the C-string generated by all of the possible volume id values would fit within 16 bytes.
AFAIK We don't ship AFS in rhel. RHEL is not affected, fedora probably is though.
I take it back.. it looks as though we DO enable AFS. kernel-x86_64.config:CONFIG_AFS_FS=m I never saw this feature request come in..
(In reply to Wade Mealing from comment #6) > AFAIK We don't ship AFS in rhel. Since 9.2, AFS is built by Red Hat and delivered to its partner (AuriStor) for distribution to end users. > > RHEL is not affected, fedora probably is though. As explained in Comment 4, https://bugzilla.redhat.com/show_bug.cgi?id=2273276#c4, due to restrictions on the range of volume ids that can be fetched from the network it is not possible for the stored volume ids to require more than 15 bytes plus a NUL when converted to C string representation by sprintf(). Therefore no buffer overflow can occur. Commit 6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d grew the size of idbuf[] which protects against the risk of overflow when the ability to fetch 64-bit volume ids is added in the future. No existing kernel version has such a capability.
Oh, i get the exploit, thanks for the clarification on the distribution method. I'll leave it up to prodsec if we're going to make this as 'affected' when Red Hat doesn't distribute the affected code to its customers. Since an update to the kernel package wont 'fix' anything.