Messages in this thread | | | Subject | Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line | From | He Zhe <> | Date | Fri, 21 Sep 2018 00:16:50 +0800 |
| |
On 2018年09月19日 10:43, Steven Rostedt wrote: > On Wed, 19 Sep 2018 11:39:32 +0900 > Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote: > >> On (09/19/18 10:27), He Zhe wrote: >>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote: >>>> On (09/19/18 01:17), zhe.he@windriver.com wrote: >>>>> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size) >>>>> /* save requested log_buf_len since it's too early to process it */ >>>>> static int __init log_buf_len_setup(char *str) >>>>> { >>>>> - unsigned size = memparse(str, &str); >>>>> + unsigned size; >>>> unsigned int size; >>> This is in v1 but then Steven suggested that it should be split out >>> and only keep the pure fix part here. >> Ah, I see. >> >> Hmm... memparse() returns u64 value. A user *probably* can ask the kernel >> to allocate log_buf larger than 'unsigned int'. >> >> So may be I'd do two fixes here: >> >> First - switch to u64 size. >> Second - check for NULL str. >> >> >> Steven, Petr, what do you think? >> > I think I would switch it around. Check for NULL first, and then switch > to u64. It was always an int, do we need to backport converting it to > u64 to stable? The NULL check is a definite, the overflow of int > shouldn't crash anything.
To switch to u64, several variables need to be adjusted to new type to aligned with new_log_buf_len. And currently new_log_buf_len is passed to memblock_virt_alloc(phys_addr_t, phys_addr_t). So we can't simply define new_log_buf_len as u64. We need to define it as phys_addr_t tomake it work well for both 32bit and 64bit arches, since a 32-bit architecture can set ARCH_PHYS_ADDR_T_64BIT if it needs a 64-bit phys_addr_t.
What do you think?
#ifdef CONFIG_PHYS_ADDR_T_64BIT typedef u64 phys_addr_t; #else typedef u32 phys_addr_t; #endif
Thanks, Zhe
> -- Steve >
| |