CVE-2024-27036 Affecting kernel-syms-azure package, versions <6.4.0-150600.8.5.1
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-SLES156-KERNELSYMSAZURE-7346816
- published22 Jun 2024
- disclosed21 Jun 2024
Introduced: 21 Jun 2024
CVE-2024-27036 (opens in a new tab)How to fix?
Upgrade SLES:15.6 kernel-syms-azure to version 6.4.0-150600.8.5.1 or higher.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-syms-azure package and not the kernel-syms-azure package as distributed by SLES.
See How to fix? for SLES:15.6 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix writeback data corruption
cifs writeback doesn't correctly handle the case where cifs_extend_writeback() hits a point where it is considering an additional folio, but this would overrun the wsize - at which point it drops out of the xarray scanning loop and calls xas_pause(). The problem is that xas_pause() advances the loop counter - thereby skipping that page.
What needs to happen is for xas_reset() to be called any time we decide we don't want to process the page we're looking at, but rather send the request we are building and start a new one.
Fix this by copying and adapting the netfslib writepages code as a temporary measure, with cifs writeback intending to be offloaded to netfslib in the near future.
This also fixes the issue with the use of filemap_get_folios_tag() causing retry of a bunch of pages which the extender already dealt with.
This can be tested by creating, say, a 64K file somewhere not on cifs (otherwise copy-offload may get underfoot), mounting a cifs share with a wsize of 64000, copying the file to it and then comparing the original file and the copy:
dd if=/dev/urandom of=/tmp/64K bs=64k count=1
mount //192.168.6.1/test /mnt -o user=...,pass=...,wsize=64000
cp /tmp/64K /mnt/64K
cmp /tmp/64K /mnt/64K
Without the fix, the cmp fails at position 64000 (or shortly thereafter).
References
- https://www.suse.com/security/cve/CVE-2024-27036.html
- https://bugzilla.suse.com/1223810
- https://git.kernel.org/stable/c/65f2ced695982ccd516196d0a9447d85dbe2eed5
- https://git.kernel.org/stable/c/844b4e132f57f1333dc79feaa035075a096762e4
- https://git.kernel.org/stable/c/e45deec35bf7f1f4f992a707b2d04a8c162f2240
- https://git.kernel.org/stable/c/f3dc1bdb6b0b0693562c7c54a6c28bafa608ba3c