GHSA-GRQ5-97JG-XJFP
Vulnerability from github – Published: 2024-11-19 03:31 – Updated: 2025-11-04 00:32In the Linux kernel, the following vulnerability has been resolved:
ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()
Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():
[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...]
Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM.
In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.
Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.
{
"affected": [],
"aliases": [
"CVE-2024-50265"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-19T02:16:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()\n\nSyzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():\n\n[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12\n[ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry\n[ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004\n[...]\n[ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0\n[...]\n[ 57.331328] Call Trace:\n[ 57.331477] \u003cTASK\u003e\n[...]\n[ 57.333511] ? do_user_addr_fault+0x3e5/0x740\n[ 57.333778] ? exc_page_fault+0x70/0x170\n[ 57.334016] ? asm_exc_page_fault+0x2b/0x30\n[ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10\n[ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0\n[ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0\n[ 57.335164] ocfs2_xa_set+0x704/0xcf0\n[ 57.335381] ? _raw_spin_unlock+0x1a/0x40\n[ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20\n[ 57.335915] ? trace_preempt_on+0x1e/0x70\n[ 57.336153] ? start_this_handle+0x16c/0x500\n[ 57.336410] ? preempt_count_sub+0x50/0x80\n[ 57.336656] ? _raw_read_unlock+0x20/0x40\n[ 57.336906] ? start_this_handle+0x16c/0x500\n[ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0\n[ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0\n[ 57.337706] ? ocfs2_start_trans+0x13d/0x290\n[ 57.337971] ocfs2_xattr_set+0xb13/0xfb0\n[ 57.338207] ? dput+0x46/0x1c0\n[ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30\n[ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30\n[ 57.338948] __vfs_removexattr+0x92/0xc0\n[ 57.339182] __vfs_removexattr_locked+0xd5/0x190\n[ 57.339456] ? preempt_count_sub+0x50/0x80\n[ 57.339705] vfs_removexattr+0x5f/0x100\n[...]\n\nReproducer uses faultinject facility to fail ocfs2_xa_remove() -\u003e\nocfs2_xa_value_truncate() with -ENOMEM.\n\nIn this case the comment mentions that we can return 0 if\nocfs2_xa_cleanup_value_truncate() is going to wipe the entry\nanyway. But the following \u0027rc\u0027 check is wrong and execution flow do\n\u0027ocfs2_xa_remove_entry(loc);\u0027 twice:\n* 1st: in ocfs2_xa_cleanup_value_truncate();\n* 2nd: returning back to ocfs2_xa_remove() instead of going to \u0027out\u0027.\n\nFix this by skipping the 2nd removal of the same entry and making\nsyzkaller repro happy.",
"id": "GHSA-grq5-97jg-xjfp",
"modified": "2025-11-04T00:32:03Z",
"published": "2024-11-19T03:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50265"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b63c0e01fba40e3992bc627272ec7b618ccaef7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/168a9b8303fcb0317db4c06b23ce1c0ce2af4e10"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b5369528ee63c88371816178a05b5e664c87386"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38cbf13b2e7a31362babe411f7c2c3c52cd2734b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a7e6dcf90fe7721d0863067b6ca9a9442134692"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/86dd0e8d42828923c68ad506933336bcd6f2317d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dcc8fe8c83145041cb6c80cac21f6173a3ff0204"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dd73c942eed76a014c7a5597e6926435274d2c4c"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"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 | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.