Bugzilla – Bug 1213122
VUL-0: CVE-2023-37454: kernel: use-after-free write operation in the udf_put_super
Last modified: 2024-12-24 09:42:55 UTC
CVE-2023-37454 An issue was discovered in the Linux kernel through 6.4.2. A crafted UDF filesystem image causes a use-after-free write operation in the udf_put_super and udf_close_lvid functions in fs/udf/super.c. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-37454 https://bugzilla.redhat.com/show_bug.cgi?id=2221038 https://www.cve.org/CVERecord?id=CVE-2023-37454 https://lore.kernel.org/all/00000000000056e02f05dfb6e11a@google.com/T/ https://syzkaller.appspot.com/bug?extid=26873a72980f8fa8bc55 https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57 https://syzkaller.appspot.com/bug?extid=61564e5023b7229ec85d
So I don't think this CVE is valid. When I was looking at it upstream the syzbot reproducer seems to modify the block device while the filesystem is mounted and that is generally not something we protect against and kernel crashes are expected - write access to a buffer cache of a mounted device (i.e., to /dev/sda or /dev/loop0 as in this reproducer) is effectively the same as write access to arbitrary memory => a full system control. I can do a more detailed analysis of the reproducer when I return from vacation (so far I can just sees the reproducer mounts a filesystem through loop mount and then opens the device but it is not 100% clear how it modifies it) but frankly I don't find this "syzbot hit some kernel crash, file a CVE for it" attitude helpful as a lot of syzbot reproducers are just doing stuff that is expected to cause troubles.
DISPUTE candidate I would say.
Sorry I forgot about this bug after vacation but I've checked the reproducer now. I'm not quite able to reproduce the KASAN error in my test VM but checking the strace it really seem to just spawn 8 threads which create loop devices, mount them (which fails) and tear them down. Now what I suspect occasionally happens is that two syzbot threads start operating on the same loop device and step on each others toes because what I *can* see in my testing are occasional errors like: [ 3044.517398] I/O error, dev loop4, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2 which means that one thread torn down loop device under another thread's hands. And when that happens in particularly unlucky fashion I guess the KASAN warning could trigger (as I described in comment 3). Anyway, I don't think there's a security issue to fix so yes, please dispute. Thanks!
I just filed a CVE dispute request with Mitre, referencing to above comment.
Mitre has updated their entry too: An issue was discovered in the Linux kernel through 6.4.2. A crafted UDF filesystem image causes a use-after-free write operation in the udf_put_super and udf_close_lvid functions in fs/udf/super.c. NOTE: the suse.com reference has a different perspective about this. (not helpful I think)