Bug 1213122 (CVE-2023-37454) - VUL-0: CVE-2023-37454: kernel: use-after-free write operation in the udf_put_super
Summary: VUL-0: CVE-2023-37454: kernel: use-after-free write operation in the udf_put_...
Status: RESOLVED WONTFIX
Alias: CVE-2023-37454
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/371497/
Whiteboard: CVSSv3.1:SUSE:CVE-2023-37454:6.7:(AV:...
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-07 07:09 UTC by Robert Frohl
Modified: 2024-12-24 09:42 UTC (History)
3 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 3 Jan Kara 2023-07-07 11:08:30 UTC
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.
Comment 4 Marcus Meissner 2023-08-31 13:58:06 UTC
DISPUTE candidate I would say.
Comment 5 Jan Kara 2023-08-31 17:38:01 UTC
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!
Comment 6 Marcus Meissner 2023-09-07 08:01:56 UTC
I just filed a CVE dispute request with Mitre, referencing to above comment.
Comment 7 Marcus Meissner 2023-10-30 09:03:11 UTC
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)