|
Bugzilla – Full Text Bug Listing |
| Summary: | VUL-0: CVE-2023-52786: kernel: ext4: fix racy may inline data check in dio write | ||
|---|---|---|---|
| Product: | [Novell Products] SUSE Security Incidents | Reporter: | SMASH SMASH <smash_bz> |
| Component: | Incidents | Assignee: | Security Team bot <security-team> |
| Status: | NEW --- | QA Contact: | Security Team bot <security-team> |
| Severity: | Minor | ||
| Priority: | P3 - Medium | CC: | carlos.lopez, jack, mhocko |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://smash.suse.de/issue/407171/ | ||
| Whiteboard: | CVSSv3.1:SUSE:CVE-2023-52786:3.6:(AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:L) | ||
| Found By: | Security Response Team | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Jack do I get it right that the whole CVE is about triggering WARN which could panic with panic_on_warn or are there any other potential security risks? Yes, wrt security the WARN_ON is the only possible concern. There's also the functional bug that if the race happens direct IO will return -ERANGE error (weird one, I know) but I don't see how that could be security relevant either. Anyway I guess we want this as a bugfix for SLE15-SP6 (nothing else should be affected). Taking the bug. I've pushed the fix to SLE15-SP6 branch. The problem was introduced by 310ee0902b8d ("ext4: allow concurrent unaligned dio overwrites") which we carry only there so nothing else is affected.
All should be done from my side, reassigning back to security team.
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix racy may inline data check in dio write syzbot reports that the following warning from ext4_iomap_begin() triggers as of the commit referenced below: if (WARN_ON_ONCE(ext4_has_inline_data(inode))) return -ERANGE; This occurs during a dio write, which is never expected to encounter an inode with inline data. To enforce this behavior, ext4_dio_write_iter() checks the current inline state of the inode and clears the MAY_INLINE_DATA state flag to either fall back to buffered writes, or enforce that any other writers in progress on the inode are not allowed to create inline data. The problem is that the check for existing inline data and the state flag can span a lock cycle. For example, if the ilock is originally locked shared and subsequently upgraded to exclusive, another writer may have reacquired the lock and created inline data before the dio write task acquires the lock and proceeds. The commit referenced below loosens the lock requirements to allow some forms of unaligned dio writes to occur under shared lock, but AFAICT the inline data check was technically already racy for any dio write that would have involved a lock cycle. Regardless, lift clearing of the state bit to the same lock critical section that checks for preexisting inline data on the inode to close the race. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-52786 https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2023/CVE-2023-52786.mbox https://git.kernel.org/stable/c/e3b83d87c93eb6fc96a80b5e8527f7dc9f5a11bc https://git.kernel.org/stable/c/7343c23ebcadbedc23a7063d1e24d976eccb0d0d https://git.kernel.org/stable/c/ce56d21355cd6f6937aca32f1f44ca749d1e4808 https://www.cve.org/CVERecord?id=CVE-2023-52786