[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-changelog] [xen stable-4.12] x86/boot: Don't leak the module_map allocation in __start_xen()



commit 31f1bab3fee14381b75723d0738bbdecb9ec82bf
Author:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Fri Jul 19 16:10:43 2019 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Fri Jul 19 16:10:43 2019 +0200

    x86/boot: Don't leak the module_map allocation in __start_xen()
    
    Ever since its introducion in c/s 436fb462 "x86/microcode: enable boot
    time (pre-Dom0) loading", the allocation has gone un-freed, and has its 
final
    use as part of constructing dom0.
    
    Xen already consideres it an error to have more than a single 
unaccounted-for
    module (again, logic from the same change), and will only pass the first one
    to dom0 as the initrd.
    
    Instead of having an 8 byte pointer to a bitmap which won't exceed 4 bits 
wide
    in any production scenario (dom0 kernel, initrd, XSM blob and microcode 
blob),
    allocate module_map[] on the stack and add a sanity bound for 
mbi->mods_count.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    master commit: 9b757bdc1794d012f5d784de54d5884e425622e0
    master date: 2019-05-13 10:35:37 +0100
---
 xen/arch/x86/setup.c | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 3440794275..7f7877ac24 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -680,7 +680,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     unsigned int initrdidx, num_parked = 0;
     multiboot_info_t *mbi;
     module_t *mod;
-    unsigned long nr_pages, raw_max_page, modules_headroom, *module_map;
+    unsigned long nr_pages, raw_max_page, modules_headroom, module_map[1];
     int i, j, e820_warn = 0, bytes = 0;
     bool acpi_boot_table_init_done = false, relocated = false;
     int ret;
@@ -840,6 +840,17 @@ void __init noreturn __start_xen(unsigned long mbi_p)
     if ( !(mbi->flags & MBI_MODULES) || (mbi->mods_count == 0) )
         panic("dom0 kernel not specified. Check bootloader configuration\n");
 
+    /* Check that we don't have a silly number of modules. */
+    if ( mbi->mods_count > sizeof(module_map) * 8 )
+    {
+        mbi->mods_count = sizeof(module_map) * 8;
+        printk("Excessive multiboot modules - using the first %u only\n",
+               mbi->mods_count);
+    }
+
+    bitmap_fill(module_map, mbi->mods_count);
+    __clear_bit(0, module_map); /* Dom0 kernel is always first */
+
     if ( pvh_boot )
     {
         /* pvh_init() already filled in e820_raw */
@@ -1578,10 +1589,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
     init_IRQ();
 
-    module_map = xmalloc_array(unsigned long, BITS_TO_LONGS(mbi->mods_count));
-    bitmap_fill(module_map, mbi->mods_count);
-    __clear_bit(0, module_map); /* Dom0 kernel is always first */
-
     xsm_multiboot_init(module_map, mbi);
 
     microcode_grab_module(module_map, mbi);
--
generated by git-patchbot for /home/xen/git/xen.git#stable-4.12

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/xen-changelog

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.