linux-kernel - Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Sep 2018 12:30:56 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     He Zhe <zhe.he@...driver.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        <pmladek@...e.com>, <sergey.senozhatsky@...il.com>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] printk: Fix panic caused by passing log_buf_len
 to command line

On Fri, 21 Sep 2018 00:16:50 +0800
He Zhe <zhe.he@...driver.com> wrote:

> On 2018年09月19日 10:43, Steven Rostedt wrote:
> > On Wed, 19 Sep 2018 11:39:32 +0900
> > Sergey Senozhatsky <sergey.senozhatsky.work@...il.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@...driver.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.  
> 

Hi Zhe,

> 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.

The above explanation verifies more that the NULL pointer check needs
to be first, and that the change in size should not be backported to
stable because it has a high risk to doing the change as compared to it
being a problem for older kernels.

> 
> What do you think?

Sounds good to me.

What do others think?

-- Steve