| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2024-56613: sched/numa: fix memory leak due to the overwritten vma->numab_state |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| sched/numa: fix memory leak due to the overwritten vma->numab_state |
| |
| [Problem Description] |
| When running the hackbench program of LTP, the following memory leak is |
| reported by kmemleak. |
| |
| # /opt/ltp/testcases/bin/hackbench 20 thread 1000 |
| Running with 20*40 (== 800) tasks. |
| |
| # dmesg | grep kmemleak |
| ... |
| kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak) |
| kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak) |
| |
| # cat /sys/kernel/debug/kmemleak |
| unreferenced object 0xffff888cd8ca2c40 (size 64): |
| comm "hackbench", pid 17142, jiffies 4299780315 |
| hex dump (first 32 bytes): |
| ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I..... |
| 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
| backtrace (crc bff18fd4): |
| [<ffffffff81419a89>] __kmalloc_cache_noprof+0x2f9/0x3f0 |
| [<ffffffff8113f715>] task_numa_work+0x725/0xa00 |
| [<ffffffff8110f878>] task_work_run+0x58/0x90 |
| [<ffffffff81ddd9f8>] syscall_exit_to_user_mode+0x1c8/0x1e0 |
| [<ffffffff81dd78d5>] do_syscall_64+0x85/0x150 |
| [<ffffffff81e0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e |
| ... |
| |
| This issue can be consistently reproduced on three different servers: |
| * a 448-core server |
| * a 256-core server |
| * a 192-core server |
| |
| [Root Cause] |
| Since multiple threads are created by the hackbench program (along with |
| the command argument 'thread'), a shared vma might be accessed by two or |
| more cores simultaneously. When two or more cores observe that |
| vma->numab_state is NULL at the same time, vma->numab_state will be |
| overwritten. |
| |
| Although current code ensures that only one thread scans the VMAs in a |
| single 'numa_scan_period', there might be a chance for another thread |
| to enter in the next 'numa_scan_period' while we have not gotten till |
| numab_state allocation [1]. |
| |
| Note that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000` |
| cannot the reproduce the issue. It is verified with 200+ test runs. |
| |
| [Solution] |
| Use the cmpxchg atomic operation to ensure that only one thread executes |
| the vma->numab_state assignment. |
| |
| [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/ |
| |
| The Linux kernel CVE team has assigned CVE-2024-56613 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.4 with commit ef6a22b70f6d90449a5c797b8968a682824e2011 and fixed in 6.6.66 with commit 8f149bcc4d91ac92b32ff4949b291e6ed883dc42 |
| Issue introduced in 6.4 with commit ef6a22b70f6d90449a5c797b8968a682824e2011 and fixed in 6.12.5 with commit a71ddd5b87cda687efa28e049e85e923689bcef9 |
| Issue introduced in 6.4 with commit ef6a22b70f6d90449a5c797b8968a682824e2011 and fixed in 6.13 with commit 5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2024-56613 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| kernel/sched/fair.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/8f149bcc4d91ac92b32ff4949b291e6ed883dc42 |
| https://git.kernel.org/stable/c/a71ddd5b87cda687efa28e049e85e923689bcef9 |
| https://git.kernel.org/stable/c/5f1b64e9a9b7ee9cfd32c6b2fab796e29bfed075 |
