Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len to command line

[He Zhe]

On 2018å09æ19æ 10:43, Steven Rostedt wrote:
> On Wed, 19 Sep 2018 11:39:32 +0900
> Sergey Senozhatsky <sergey.senozhatsky.work@xxxxxxxxx> 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@xxxxxxxxxxxxx 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
>