CVE-2024-56780

Source
https://nvd.nist.gov/vuln/detail/CVE-2024-56780
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-56780.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2024-56780
Downstream
Related
Published
2025-01-08T18:15:18Z
Modified
2025-08-09T20:01:27Z
Severity
  • 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

quota: flush quotareleasework upon quota writeback

One of the paths quota writeback is called from is:

freezesuper() syncfilesystem() ext4syncfs() dquotwritebackdquots()

Since we currently don't always flush the quotareleasework queue in this path, we can end up with the following race:

  1. dquot are added to releasing_dquots list during regular operations.
  2. FS Freeze starts, however, this does not flush the quotareleasework queue.
  3. Freeze completes.
  4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARN_ON since transaction gets started during frozen state:

    ext4journalcheckstart+0x28/0x110 [ext4] (unreliable) _ext4journalstartsb+0x64/0x1c0 [ext4] ext4releasedquot+0x90/0x1d0 [ext4] quotarelease_workfn+0x43c/0x4d0

Which is the following line:

WARNON(sb->swriters.frozen == SBFREEZECOMPLETE);

Which ultimately results in generic/390 failing due to dmesg noise. This was detected on powerpc machine 15 cores.

To avoid this, make sure to flush the workqueue during dquotwritebackdquots() so we dont have any pending workitems after freeze.

References

Affected packages