Linux vulnerability

In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...

Published 12 Nov 2025Updated 8 Sep 20266 sources
CVSS 0.0

What happened

In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...

Affected versions

Linux: 3e6ff207cd5bd924ad94cd1a7c633bcdac0ba1cb through before 8df2eedd371a1c24ecc4283581299d7737dfcd06 (git); bcacb52a985f1b6d280f698a470b873dfe52728a through before f846eacde280ecc3daedfe001580e3033565179e (git); 8ea87e34792258825d290f4dc5216276e91cb224 through before f12039df1515d5daf7d92e586ece5cefeb39561b (git); ac6f420291b3fee1113f21d612fa88b628afab5b through before 8a09a62f0c8c6123c2f1864ed6d5f9eb144afaf0 (git); ac6f420291b3fee1113f21d612fa88b628afab5b through before 72b7ceca857f38a8ca7c5629feffc63769638974 (git); a5abba5e0e586e258ded3e798fe5f69c66fec198 (git); 6f3821acd7c3143145999248087de5fb4b48cf26 (git); ab6cfcf8ed2c7496f55d020b65b1d8cd55d9a2cb (git); 6.1.120 through before 6.1.178 (semver); 6.6.64 through before 6.6.114 (semver); 6.12.4 through before 6.12.54 (semver); 5.4.287 through before 5.5 (semver); 5.10.231 through before 5.11 (semver); 5.15.174 through before 5.16 (semver); 6.13; V3.1.6 through before * (custom) Fixed: See vendor advisory.

Why it matters

Review the vendor advisory and exposure of the affected product to determine operational impact.

Detection & mitigation

  • Apply vendor-provided updates or mitigations.
  • Review affected product exposure and access logs.

Public PoC references

No public PoC reference has passed the current publication threshold.