| 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-46847: mm: vmalloc: ensure vmap_block is initialised before adding to queue |
| |
| Description |
| =========== |
| |
| In the Linux kernel, the following vulnerability has been resolved: |
| |
| mm: vmalloc: ensure vmap_block is initialised before adding to queue |
| |
| Commit 8c61291fd850 ("mm: fix incorrect vbq reference in |
| purge_fragmented_block") extended the 'vmap_block' structure to contain a |
| 'cpu' field which is set at allocation time to the id of the initialising |
| CPU. |
| |
| When a new 'vmap_block' is being instantiated by new_vmap_block(), the |
| partially initialised structure is added to the local 'vmap_block_queue' |
| xarray before the 'cpu' field has been initialised. If another CPU is |
| concurrently walking the xarray (e.g. via vm_unmap_aliases()), then it |
| may perform an out-of-bounds access to the remote queue thanks to an |
| uninitialised index. |
| |
| This has been observed as UBSAN errors in Android: |
| |
| | Internal error: UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP |
| | |
| | Call trace: |
| | purge_fragmented_block+0x204/0x21c |
| | _vm_unmap_aliases+0x170/0x378 |
| | vm_unmap_aliases+0x1c/0x28 |
| | change_memory_common+0x1dc/0x26c |
| | set_memory_ro+0x18/0x24 |
| | module_enable_ro+0x98/0x238 |
| | do_init_module+0x1b0/0x310 |
| |
| Move the initialisation of 'vb->cpu' in new_vmap_block() ahead of the |
| addition to the xarray. |
| |
| The Linux kernel CVE team has assigned CVE-2024-46847 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 6.6.37 with commit 88e0ad40d08a73a74c597e69f4cd2d1fba3838b5 and fixed in 6.6.51 with commit 1b2770e27d6d952f491bb362b657e5b2713c3efd |
| Issue introduced in 6.10 with commit 8c61291fd8500e3b35c7ec0c781b273d8cc96cde and fixed in 6.10.10 with commit 6cf74e0e5e3ab5d5c9defb4c73dad54d52224671 |
| Issue introduced in 6.10 with commit 8c61291fd8500e3b35c7ec0c781b273d8cc96cde and fixed in 6.11 with commit 3e3de7947c751509027d26b679ecd243bc9db255 |
| Issue introduced in 6.9.8 with commit 9983b81579be3403f5cc44b11f66c6c8bea6547f |
| |
| 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-46847 |
| 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: |
| mm/vmalloc.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/1b2770e27d6d952f491bb362b657e5b2713c3efd |
| https://git.kernel.org/stable/c/6cf74e0e5e3ab5d5c9defb4c73dad54d52224671 |
| https://git.kernel.org/stable/c/3e3de7947c751509027d26b679ecd243bc9db255 |
