GHSA-5MVF-MW2H-9F35
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-19 18:32In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix memory leak in __add_inode_ref()
Line 1169 (#3) allocates a memory chunk for victim_name by kmalloc(), but when the function returns in line 1184 (#4) victim_name allocated by line 1169 (#3) is not freed, which will lead to a memory leak. There is a similar snippet of code in this function as allocating a memory chunk for victim_name in line 1104 (#1) as well as releasing the memory in line 1116 (#2).
We should kfree() victim_name when the return value of backref_in_log() is less than zero and before the function returns in line 1184 (#4).
1057 static inline int __add_inode_ref(struct btrfs_trans_handle trans, 1058 struct btrfs_root root, 1059 struct btrfs_path path, 1060 struct btrfs_root log_root, 1061 struct btrfs_inode dir, 1062 struct btrfs_inode inode, 1063 u64 inode_objectid, u64 parent_objectid, 1064 u64 ref_index, char name, int namelen, 1065 int search_done) 1066 {
1104 victim_name = kmalloc(victim_name_len, GFP_NOFS); // #1: kmalloc (victim_name-1) 1105 if (!victim_name) 1106 return -ENOMEM;
1112 ret = backref_in_log(log_root, &search_key, 1113 parent_objectid, victim_name, 1114 victim_name_len); 1115 if (ret < 0) { 1116 kfree(victim_name); // #2: kfree (victim_name-1) 1117 return ret; 1118 } else if (!ret) {
1169 victim_name = kmalloc(victim_name_len, GFP_NOFS); // #3: kmalloc (victim_name-2) 1170 if (!victim_name) 1171 return -ENOMEM;
1180 ret = backref_in_log(log_root, &search_key, 1181 parent_objectid, victim_name, 1182 victim_name_len); 1183 if (ret < 0) { 1184 return ret; // #4: missing kfree (victim_name-2) 1185 } else if (!ret) {
1241 return 0; 1242 }
{
"affected": [],
"aliases": [
"CVE-2021-47585"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T15:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix memory leak in __add_inode_ref()\n\nLine 1169 (#3) allocates a memory chunk for victim_name by kmalloc(),\nbut when the function returns in line 1184 (#4) victim_name allocated\nby line 1169 (#3) is not freed, which will lead to a memory leak.\nThere is a similar snippet of code in this function as allocating a memory\nchunk for victim_name in line 1104 (#1) as well as releasing the memory\nin line 1116 (#2).\n\nWe should kfree() victim_name when the return value of backref_in_log()\nis less than zero and before the function returns in line 1184 (#4).\n\n1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans,\n1058 \t\t\t\t struct btrfs_root *root,\n1059 \t\t\t\t struct btrfs_path *path,\n1060 \t\t\t\t struct btrfs_root *log_root,\n1061 \t\t\t\t struct btrfs_inode *dir,\n1062 \t\t\t\t struct btrfs_inode *inode,\n1063 \t\t\t\t u64 inode_objectid, u64 parent_objectid,\n1064 \t\t\t\t u64 ref_index, char *name, int namelen,\n1065 \t\t\t\t int *search_done)\n1066 {\n\n1104 \tvictim_name = kmalloc(victim_name_len, GFP_NOFS);\n\t// #1: kmalloc (victim_name-1)\n1105 \tif (!victim_name)\n1106 \t\treturn -ENOMEM;\n\n1112\tret = backref_in_log(log_root, \u0026search_key,\n1113\t\t\tparent_objectid, victim_name,\n1114\t\t\tvictim_name_len);\n1115\tif (ret \u003c 0) {\n1116\t\tkfree(victim_name); // #2: kfree (victim_name-1)\n1117\t\treturn ret;\n1118\t} else if (!ret) {\n\n1169 \tvictim_name = kmalloc(victim_name_len, GFP_NOFS);\n\t// #3: kmalloc (victim_name-2)\n1170 \tif (!victim_name)\n1171 \t\treturn -ENOMEM;\n\n1180 \tret = backref_in_log(log_root, \u0026search_key,\n1181 \t\t\tparent_objectid, victim_name,\n1182 \t\t\tvictim_name_len);\n1183 \tif (ret \u003c 0) {\n1184 \t\treturn ret; // #4: missing kfree (victim_name-2)\n1185 \t} else if (!ret) {\n\n1241 \treturn 0;\n1242 }",
"id": "GHSA-5mvf-mw2h-9f35",
"modified": "2024-08-19T18:32:03Z",
"published": "2024-06-19T15:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47585"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/005d9292b5b2e71a009f911bd85d755009b37242"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/493ff661d434d6bdf02e3a21adae04d7a0b4265d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f35838a6930296fc1988764cfa54cb3f705c0665"
}
],
"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.