fkie_cve-2021-47585
Vulnerability from fkie_nvd
Published
2024-06-19 15:15
Modified
2024-11-21 06:36
Severity ?
Summary
In 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 }
References
Impacted products
Vendor | Product | Version | |
---|---|---|---|
linux | linux_kernel | * | |
linux | linux_kernel | * |
{ configurations: [ { nodes: [ { cpeMatch: [ { criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", matchCriteriaId: "A657B2D0-5B9D-42BE-A3BF-228DBC1B057C", versionEndExcluding: "5.10.88", versionStartIncluding: "5.5", vulnerable: true, }, { criteria: "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", matchCriteriaId: "11274E95-438A-449A-B100-01B2B0046669", versionEndExcluding: "5.15.11", versionStartIncluding: "5.11", vulnerable: true, }, ], negate: false, operator: "OR", }, ], }, ], cveTags: [], descriptions: [ { lang: "en", value: "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, &search_key,\n1113\t\t\tparent_objectid, victim_name,\n1114\t\t\tvictim_name_len);\n1115\tif (ret < 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, &search_key,\n1181 \t\t\tparent_objectid, victim_name,\n1182 \t\t\tvictim_name_len);\n1183 \tif (ret < 0) {\n1184 \t\treturn ret; // #4: missing kfree (victim_name-2)\n1185 \t} else if (!ret) {\n\n1241 \treturn 0;\n1242 }", }, { lang: "es", value: "En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: corrige la pérdida de memoria en __add_inode_ref() La línea 1169 (#3) asigna un fragmento de memoria para victim_name mediante kmalloc(), pero cuando la función regresa en la línea 1184 (#4) victim_name asignado por la línea 1169 (#3) no se libera, lo que provocará una pérdida de memoria. Hay un fragmento de código similar en esta función para asignar un fragmento de memoria para victim_name en la línea 1104 (n.º 1), así como para liberar la memoria en la línea 1116 (n.º 2). Deberíamos kfree() victim_name cuando el valor de retorno de backref_in_log() sea menor que cero y antes de que la función regrese en la línea 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, 63 u64 inode_objectid, u64 parent_objectid, 1064 u64 ref_index, char *nombre, int nombrelen, 1065 int *search_done) 1066 { 1104 nombre_víctima = kmalloc(nombre_víctima_len, GFP_NOFS); // #1: kmalloc (nombre_víctima-1) 1105 if (!nombre_víctima) 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(nombre_víctima); // #2: kfree (nombre_víctima-1) 1117 return ret; 1118 } else if (!ret) { 1169 nombre_víctima = kmalloc(nombre_víctima_len, GFP_NOFS); // #3: kmalloc (nombre_víctima-2) 1170 if (!nombre_víctima) 1171 return -ENOMEM; 1180 ret = backref_in_log(log_root, &search_key, 1181 parent_objectid, victim_name, 1182 victim_name_len); 1183 si (ret < 0) { 1184 retorno ret; // #4: falta kfree (nombre_víctima-2) 1185 } else if (!ret) { 1241 return 0; 1242 }", }, ], id: "CVE-2021-47585", lastModified: "2024-11-21T06:36:36.300", metrics: { cvssMetricV31: [ { cvssData: { attackComplexity: "LOW", attackVector: "LOCAL", availabilityImpact: "HIGH", baseScore: 5.5, baseSeverity: "MEDIUM", confidentialityImpact: "NONE", integrityImpact: "NONE", privilegesRequired: "LOW", scope: "UNCHANGED", userInteraction: "NONE", vectorString: "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", version: "3.1", }, exploitabilityScore: 1.8, impactScore: 3.6, source: "nvd@nist.gov", type: "Primary", }, ], }, published: "2024-06-19T15:15:53.057", references: [ { source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67", tags: [ "Patch", ], url: "https://git.kernel.org/stable/c/005d9292b5b2e71a009f911bd85d755009b37242", }, { source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67", tags: [ "Patch", ], url: "https://git.kernel.org/stable/c/493ff661d434d6bdf02e3a21adae04d7a0b4265d", }, { source: "416baaa9-dc9f-4396-8d5f-8c081fb06d67", tags: [ "Patch", ], url: "https://git.kernel.org/stable/c/f35838a6930296fc1988764cfa54cb3f705c0665", }, { source: "af854a3a-2127-422b-91ae-364da2661108", tags: [ "Patch", ], url: "https://git.kernel.org/stable/c/005d9292b5b2e71a009f911bd85d755009b37242", }, { source: "af854a3a-2127-422b-91ae-364da2661108", tags: [ "Patch", ], url: "https://git.kernel.org/stable/c/493ff661d434d6bdf02e3a21adae04d7a0b4265d", }, { source: "af854a3a-2127-422b-91ae-364da2661108", tags: [ "Patch", ], url: "https://git.kernel.org/stable/c/f35838a6930296fc1988764cfa54cb3f705c0665", }, ], sourceIdentifier: "416baaa9-dc9f-4396-8d5f-8c081fb06d67", vulnStatus: "Modified", weaknesses: [ { description: [ { lang: "en", value: "CWE-401", }, ], source: "nvd@nist.gov", type: "Primary", }, ], }
Log in or create an account to share your comment.
Security Advisory comment format.
This schema specifies the format of a comment related to a security advisory.
Title of the comment
Description of the comment
Loading…
Loading…
Loading…
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.