Bugzilla – Bug 1214050
VUL-0: CVE-2023-4205: kernel-source-rt,kernel-source-azure,kernel-source: reiserfs: out of bounds write in do_journal_end()
Last modified: 2023-08-11 09:13:03 UTC
CVE-2023-4205 A flaw in the Linux Kernel found. Out of bounds memory access can happen in do_journal_end function when fail array-index-out-of-bounds in fs/reiserfs/journal.c happens. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4205 https://bugzilla.redhat.com/show_bug.cgi?id=2228101 https://www.cve.org/CVERecord?id=CVE-2023-4205 https://access.redhat.com/security/cve/CVE-2023-4205 https://www.spinics.net/lists/kernel/msg4876594.html
It might be a false positive: https://www.spinics.net/lists/reiserfs-devel/msg07351.html
I'm not really familiar with the reiserfs codebase to comment on the viability of this being exploited, and I do not see any further upstream discussion yet. Perhaps Jan knows more about this. We can certainly consider a backport if indeed upstream deems this is an issue that requires a fix and produces one.
OK, so I took some time to understand the code and the report seems completely bogus AFAICT. UBSAN is complaining about access that is perfectly fine (just incorrectly detected variable-length array) and the theory the guy has that maybe there could be more members on the list than there's space in the block is wrong as well because reiserfs actually does check the list has no more members than journal->j_trans_max when adding new members to the list. More details in [1]. So please dispute this CVE as invalid. Thanks! [1] https://lore.kernel.org/all/20230809153207.zokdmoco4lwa5s6b@quack3
Reassigning back to security team.
(In reply to Jan Kara from comment #4) > OK, so I took some time to understand the code and the report seems > completely bogus AFAICT. UBSAN is complaining about access that is perfectly > fine (just incorrectly detected variable-length array) and the theory the > guy has that maybe there could be more members on the list than there's > space in the block is wrong as well because reiserfs actually does check the > list has no more members than journal->j_trans_max when adding new members > to the list. More details in [1]. So please dispute this CVE as invalid. > Thanks! > > > [1] https://lore.kernel.org/all/20230809153207.zokdmoco4lwa5s6b@quack3 Many thanks for handling this, Jan. Seems like there is already more or less consensus on how to handle those in the discussion @research ml. I think from upstream perspective it is clear (basically unmaintained, scheduled for deprecation), and unless whoever submits those reports is also willing to submit fixes, it doesn't seem there will be any resources invested in doing so. I suppose the same goes for SLES, given that we have been providing upgrade paths for a long time (and customers can still use btrfs-convert to move off reiserfs). I think we generally like to provide at least read-only support even to legacy filesystems (as long as it is reasonable), but I am assuming any non-trivial reiserfs work coming from upstream (such as this one) which requires resources will be handled as WONTFIX in the future, unless there is a very specific customer requirement that justifies the effort.
CVE rejected: https://nvd.nist.gov/vuln/detail/CVE-2023-4205 https://bugzilla.redhat.com/show_bug.cgi?id=2228101