{"uuid": "e2a2a683-a5ba-41cd-971c-ae75fd78426f", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "CVE-2024-56780", "type": "seen", "source": "https://t.me/cvedetector/14717", "content": "{\n  \"Source\": \"CVE FEED\",\n  \"Title\": \"CVE-2024-56780 - Linux quota kernel Freeze\u2122 DoS Vulnerability\", \n  \"Content\": \"CVE ID : CVE-2024-56780 \nPublished : Jan. 8, 2025, 6:15 p.m. | 36\u00a0minutes ago \nDescription : In the Linux kernel, the following vulnerability has been resolved:  \n  \nquota: flush quota_release_work upon quota writeback  \n  \nOne of the paths quota writeback is called from is:  \n  \nfreeze_super()  \n  sync_filesystem()  \n    ext4_sync_fs()  \n      dquot_writeback_dquots()  \n  \nSince we currently don't always flush the quota_release_work queue in  \nthis path, we can end up with the following race:  \n  \n 1. dquot are added to releasing_dquots list during regular operations.  \n 2. FS Freeze starts, however, this does not flush the quota_release_work queue.  \n 3. Freeze completes.  \n 4. Kernel eventually tries to flush the workqueue while FS is frozen which  \n    hits a WARN_ON since transaction gets started during frozen state:  \n  \n  ext4_journal_check_start+0x28/0x110 [ext4] (unreliable)  \n  __ext4_journal_start_sb+0x64/0x1c0 [ext4]  \n  ext4_release_dquot+0x90/0x1d0 [ext4]  \n  quota_release_workfn+0x43c/0x4d0  \n  \nWhich is the following line:  \n  \n  WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);  \n  \nWhich ultimately results in generic/390 failing due to dmesg  \nnoise. This was detected on powerpc machine 15 cores.  \n  \nTo avoid this, make sure to flush the workqueue during  \ndquot_writeback_dquots() so we dont have any pending workitems after  \nfreeze. \nSeverity: 0.0 | NA \nVisit the link for more details, such as CVSS details, affected products, timeline, and more...\",\n  \"Detection Date\": \"08 Jan 2025\",\n  \"Type\": \"Vulnerability\"\n}\n\ud83d\udd39 t.me/cvedetector \ud83d\udd39", "creation_timestamp": "2025-01-08T20:00:03.000000Z"}