ghsa-28h2-465h-q5v7
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
block: Fix potential deadlock while freezing queue and acquiring sysfs_lock
For storing a value to a queue attribute, the queue_attr_store function first freezes the queue (->q_usage_counter(io)) and then acquire ->sysfs_lock. This seems not correct as the usual ordering should be to acquire ->sysfs_lock before freezing the queue. This incorrect ordering causes the following lockdep splat which we are able to reproduce always simply by accessing /sys/kernel/debug file using ls command:
[ 57.597146] WARNING: possible circular locking dependency detected [ 57.597154] 6.12.0-10553-gb86545e02e8c #20 Tainted: G W [ 57.597162] ------------------------------------------------------ [ 57.597168] ls/4605 is trying to acquire lock: [ 57.597176] c00000003eb56710 (&mm->mmap_lock){++++}-{4:4}, at: __might_fault+0x58/0xc0 [ 57.597200] but task is already holding lock: [ 57.597207] c0000018e27c6810 (&sb->s_type->i_mutex_key#3){++++}-{4:4}, at: iterate_dir+0x94/0x1d4 [ 57.597226] which lock already depends on the new lock.
[ 57.597233] the existing dependency chain (in reverse order) is: [ 57.597241] -> #5 (&sb->s_type->i_mutex_key#3){++++}-{4:4}: [ 57.597255] down_write+0x6c/0x18c [ 57.597264] start_creating+0xb4/0x24c [ 57.597274] debugfs_create_dir+0x2c/0x1e8 [ 57.597283] blk_register_queue+0xec/0x294 [ 57.597292] add_disk_fwnode+0x2e4/0x548 [ 57.597302] brd_alloc+0x2c8/0x338 [ 57.597309] brd_init+0x100/0x178 [ 57.597317] do_one_initcall+0x88/0x3e4 [ 57.597326] kernel_init_freeable+0x3cc/0x6e0 [ 57.597334] kernel_init+0x34/0x1cc [ 57.597342] ret_from_kernel_user_thread+0x14/0x1c [ 57.597350] -> #4 (&q->debugfs_mutex){+.+.}-{4:4}: [ 57.597362] __mutex_lock+0xfc/0x12a0 [ 57.597370] blk_register_queue+0xd4/0x294 [ 57.597379] add_disk_fwnode+0x2e4/0x548 [ 57.597388] brd_alloc+0x2c8/0x338 [ 57.597395] brd_init+0x100/0x178 [ 57.597402] do_one_initcall+0x88/0x3e4 [ 57.597410] kernel_init_freeable+0x3cc/0x6e0 [ 57.597418] kernel_init+0x34/0x1cc [ 57.597426] ret_from_kernel_user_thread+0x14/0x1c [ 57.597434] -> #3 (&q->sysfs_lock){+.+.}-{4:4}: [ 57.597446] __mutex_lock+0xfc/0x12a0 [ 57.597454] queue_attr_store+0x9c/0x110 [ 57.597462] sysfs_kf_write+0x70/0xb0 [ 57.597471] kernfs_fop_write_iter+0x1b0/0x2ac [ 57.597480] vfs_write+0x3dc/0x6e8 [ 57.597488] ksys_write+0x84/0x140 [ 57.597495] system_call_exception+0x130/0x360 [ 57.597504] system_call_common+0x160/0x2c4 [ 57.597516] -> #2 (&q->q_usage_counter(io)#21){++++}-{0:0}: [ 57.597530] __submit_bio+0x5ec/0x828 [ 57.597538] submit_bio_noacct_nocheck+0x1e4/0x4f0 [ 57.597547] iomap_readahead+0x2a0/0x448 [ 57.597556] xfs_vm_readahead+0x28/0x3c [ 57.597564] read_pages+0x88/0x41c [ 57.597571] page_cache_ra_unbounded+0x1ac/0x2d8 [ 57.597580] filemap_get_pages+0x188/0x984 [ 57.597588] filemap_read+0x13c/0x4bc [ 57.597596] xfs_file_buffered_read+0x88/0x17c [ 57.597605] xfs_file_read_iter+0xac/0x158 [ 57.597614] vfs_read+0x2d4/0x3b4 [ 57.597622] ksys_read+0x84/0x144 [ 57.597629] system_call_exception+0x130/0x360 [ 57.597637] system_call_common+0x160/0x2c4 [ 57.597647] -> #1 (mapping.invalidate_lock#2){++++}-{4:4}: [ 57.597661] down_read+0x6c/0x220 [ 57.597669] filemap_fault+0x870/0x100c [ 57.597677] xfs_filemap_fault+0xc4/0x18c [ 57.597684] __do_fault+0x64/0x164 [ 57.597693] __handle_mm_fault+0x1274/0x1dac [ 57.597702] handle_mm_fault+0x248/0x48 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-53689"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:26Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Fix potential deadlock while freezing queue and acquiring sysfs_lock\n\nFor storing a value to a queue attribute, the queue_attr_store function\nfirst freezes the queue (-\u003eq_usage_counter(io)) and then acquire\n-\u003esysfs_lock. This seems not correct as the usual ordering should be to\nacquire -\u003esysfs_lock before freezing the queue. This incorrect ordering\ncauses the following lockdep splat which we are able to reproduce always\nsimply by accessing /sys/kernel/debug file using ls command:\n\n[ 57.597146] WARNING: possible circular locking dependency detected\n[ 57.597154] 6.12.0-10553-gb86545e02e8c #20 Tainted: G W\n[ 57.597162] ------------------------------------------------------\n[ 57.597168] ls/4605 is trying to acquire lock:\n[ 57.597176] c00000003eb56710 (\u0026mm-\u003emmap_lock){++++}-{4:4}, at: __might_fault+0x58/0xc0\n[ 57.597200]\n but task is already holding lock:\n[ 57.597207] c0000018e27c6810 (\u0026sb-\u003es_type-\u003ei_mutex_key#3){++++}-{4:4}, at: iterate_dir+0x94/0x1d4\n[ 57.597226]\n which lock already depends on the new lock.\n\n[ 57.597233]\n the existing dependency chain (in reverse order) is:\n[ 57.597241]\n -\u003e #5 (\u0026sb-\u003es_type-\u003ei_mutex_key#3){++++}-{4:4}:\n[ 57.597255] down_write+0x6c/0x18c\n[ 57.597264] start_creating+0xb4/0x24c\n[ 57.597274] debugfs_create_dir+0x2c/0x1e8\n[ 57.597283] blk_register_queue+0xec/0x294\n[ 57.597292] add_disk_fwnode+0x2e4/0x548\n[ 57.597302] brd_alloc+0x2c8/0x338\n[ 57.597309] brd_init+0x100/0x178\n[ 57.597317] do_one_initcall+0x88/0x3e4\n[ 57.597326] kernel_init_freeable+0x3cc/0x6e0\n[ 57.597334] kernel_init+0x34/0x1cc\n[ 57.597342] ret_from_kernel_user_thread+0x14/0x1c\n[ 57.597350]\n -\u003e #4 (\u0026q-\u003edebugfs_mutex){+.+.}-{4:4}:\n[ 57.597362] __mutex_lock+0xfc/0x12a0\n[ 57.597370] blk_register_queue+0xd4/0x294\n[ 57.597379] add_disk_fwnode+0x2e4/0x548\n[ 57.597388] brd_alloc+0x2c8/0x338\n[ 57.597395] brd_init+0x100/0x178\n[ 57.597402] do_one_initcall+0x88/0x3e4\n[ 57.597410] kernel_init_freeable+0x3cc/0x6e0\n[ 57.597418] kernel_init+0x34/0x1cc\n[ 57.597426] ret_from_kernel_user_thread+0x14/0x1c\n[ 57.597434]\n -\u003e #3 (\u0026q-\u003esysfs_lock){+.+.}-{4:4}:\n[ 57.597446] __mutex_lock+0xfc/0x12a0\n[ 57.597454] queue_attr_store+0x9c/0x110\n[ 57.597462] sysfs_kf_write+0x70/0xb0\n[ 57.597471] kernfs_fop_write_iter+0x1b0/0x2ac\n[ 57.597480] vfs_write+0x3dc/0x6e8\n[ 57.597488] ksys_write+0x84/0x140\n[ 57.597495] system_call_exception+0x130/0x360\n[ 57.597504] system_call_common+0x160/0x2c4\n[ 57.597516]\n -\u003e #2 (\u0026q-\u003eq_usage_counter(io)#21){++++}-{0:0}:\n[ 57.597530] __submit_bio+0x5ec/0x828\n[ 57.597538] submit_bio_noacct_nocheck+0x1e4/0x4f0\n[ 57.597547] iomap_readahead+0x2a0/0x448\n[ 57.597556] xfs_vm_readahead+0x28/0x3c\n[ 57.597564] read_pages+0x88/0x41c\n[ 57.597571] page_cache_ra_unbounded+0x1ac/0x2d8\n[ 57.597580] filemap_get_pages+0x188/0x984\n[ 57.597588] filemap_read+0x13c/0x4bc\n[ 57.597596] xfs_file_buffered_read+0x88/0x17c\n[ 57.597605] xfs_file_read_iter+0xac/0x158\n[ 57.597614] vfs_read+0x2d4/0x3b4\n[ 57.597622] ksys_read+0x84/0x144\n[ 57.597629] system_call_exception+0x130/0x360\n[ 57.597637] system_call_common+0x160/0x2c4\n[ 57.597647]\n -\u003e #1 (mapping.invalidate_lock#2){++++}-{4:4}:\n[ 57.597661] down_read+0x6c/0x220\n[ 57.597669] filemap_fault+0x870/0x100c\n[ 57.597677] xfs_filemap_fault+0xc4/0x18c\n[ 57.597684] __do_fault+0x64/0x164\n[ 57.597693] __handle_mm_fault+0x1274/0x1dac\n[ 57.597702] handle_mm_fault+0x248/0x48\n---truncated---",
"id": "GHSA-28h2-465h-q5v7",
"modified": "2025-01-16T18:30:59Z",
"published": "2025-01-11T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53689"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be26ba96421ab0a8fa2055ccf7db7832a13c44d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f1a494df8350da2e673618627cb392a8669825dd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.