Linux Kernel up to 5.12.12 include/linux/slab.h ip_mc_clear_src memory leak

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 4.6 | $0-$5k | 0.56 |
Summary
A vulnerability identified as critical has been detected in Linux Kernel up to 5.12.12. The impacted element is the function ip_mc_clear_src in the library include/linux/slab.h. Performing a manipulation results in memory leak.
This vulnerability is identified as CVE-2021-47238. There is not any exploit available.
You should upgrade the affected component.
Details
A vulnerability, which was classified as critical, was found in Linux Kernel up to 5.12.12. This affects the function ip_mc_clear_src in the library include/linux/slab.h. The manipulation with an unknown input leads to a memory leak vulnerability. CWE is classifying the issue as CWE-401. The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory. This is going to have an impact on availability. The summary by CVE is:
In the Linux kernel, the following vulnerability has been resolved: net: ipv4: fix memory leak in ip_mc_add1_src BUG: memory leak unreferenced object 0xffff888101bc4c00 (size 32): comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................ backtrace: [] kmalloc include/linux/slab.h:558 [inline] [] kzalloc include/linux/slab.h:688 [inline] [] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline] [] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095 [] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416 [] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline] [] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423 [] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857 [] __sys_setsockopt+0x158/0x270 net/socket.c:2117 [] __do_sys_setsockopt net/socket.c:2128 [inline] [] __se_sys_setsockopt net/socket.c:2125 [inline] [] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125 [] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47 [] entry_SYSCALL_64_after_hwframe+0x44/0xae In commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when set link down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed, because it was also called in igmpv3_clear_delrec(). Rough callgraph: inetdev_destroy -> ip_mc_destroy_dev -> igmpv3_clear_delrec -> ip_mc_clear_src -> RCU_INIT_POINTER(dev->ip_ptr, NULL) However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't release in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns the NULL to dev->ip_ptr. As a result, in_dev cannot be obtained through inetdev_by_index() and then in_dev->mc_list->sources cannot be released by ip_mc_del1_src() in the sock_close. Rough call sequence goes like: sock_close -> __sock_release -> inet_release -> ip_mc_drop_socket -> inetdev_by_index -> ip_mc_leave_src -> ip_mc_del_src -> ip_mc_del1_src So we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free in_dev->mc_list->sources.
The advisory is shared at git.kernel.org. This vulnerability is uniquely identified as CVE-2021-47238 since 04/10/2024. The exploitability is told to be difficult. Technical details are known, but no exploit is available.
Upgrading to version 4.9.274, 4.14.238, 4.19.196, 5.4.128, 5.10.46 or 5.12.13 eliminates this vulnerability. Applying the patch 0dc13e75507f/6cff57eea334/1e28018b5c83/3dd2aeac2e96/ac31cc837caf/77de6ee73f54/d8e2973029b8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Product
Type
Vendor
Name
Version
- 4.9.273
- 4.14.237
- 4.19.195
- 5.4.127
- 5.10.0
- 5.10.1
- 5.10.2
- 5.10.3
- 5.10.4
- 5.10.5
- 5.10.6
- 5.10.7
- 5.10.8
- 5.10.9
- 5.10.10
- 5.10.11
- 5.10.12
- 5.10.13
- 5.10.14
- 5.10.15
- 5.10.16
- 5.10.17
- 5.10.18
- 5.10.19
- 5.10.20
- 5.10.21
- 5.10.22
- 5.10.23
- 5.10.24
- 5.10.25
- 5.10.26
- 5.10.27
- 5.10.28
- 5.10.29
- 5.10.30
- 5.10.31
- 5.10.32
- 5.10.33
- 5.10.34
- 5.10.35
- 5.10.36
- 5.10.37
- 5.10.38
- 5.10.39
- 5.10.40
- 5.10.41
- 5.10.42
- 5.10.43
- 5.10.44
- 5.10.45
- 5.12.0
- 5.12.1
- 5.12.2
- 5.12.3
- 5.12.4
- 5.12.5
- 5.12.6
- 5.12.7
- 5.12.8
- 5.12.9
- 5.12.10
- 5.12.11
- 5.12.12
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔍VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 4.8VulDB Meta Temp Score: 4.6
VulDB Base Score: 4.8
VulDB Temp Score: 4.6
VulDB Vector: 🔍
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Reliability: 🔍
Exploiting
Class: Memory leakCWE: CWE-401 / CWE-404
CAPEC: 🔍
ATT&CK: 🔍
Physical: No
Local: No
Remote: Partially
Availability: 🔍
Status: Not defined
EPSS Score: 🔍
EPSS Percentile: 🔍
Price Prediction: 🔍
Current Price Estimation: 🔍
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔍
Upgrade: Kernel 4.9.274/4.14.238/4.19.196/5.4.128/5.10.46/5.12.13
Patch: 0dc13e75507f/6cff57eea334/1e28018b5c83/3dd2aeac2e96/ac31cc837caf/77de6ee73f54/d8e2973029b8
Timeline
04/10/2024 🔍05/21/2024 🔍
05/21/2024 🔍
05/21/2024 🔍
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2021-47238 (🔍)
GCVE (CVE): GCVE-0-2021-47238
GCVE (VulDB): GCVE-100-265701
Entry
Created: 05/21/2024 20:22Changes: 05/21/2024 20:22 (58)
Complete: 🔍
Cache ID: 216::103
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
No comments yet. Languages: en.
Please log in to comment.