All of lore.kernel.org
 help / color / mirror / Atom feed
From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	yrl.pp-manager.tt@hitachi.com,
	David Rientjes <rientjes@google.com>,
	Namhyung Kim <namhyung@gmail.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH -v3] avoid null pointer access in vm_struct
Date: Wed, 24 Aug 2011 13:29:38 +0900	[thread overview]
Message-ID: <4E547E32.4030001@hitachi.com> (raw)
In-Reply-To: <20110822152505.22b58998.akpm@linux-foundation.org>

Hi Andrew,

(2011/08/23 7:25), Andrew Morton wrote:
> On Sun, 21 Aug 2011 17:21:32 +0900
> Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> wrote:
> 
>> The /proc/vmallocinfo shows information about vmalloc allocations in vmlist
>> that is a linklist of vm_struct. It, however, may access pages field of
>> vm_struct where a page was not allocated. This results in a null pointer
>> access and leads to a kernel panic.
>>
>> Why this happen:
>> In __vmalloc_node_range() called from vmalloc(), newly allocated vm_struct
>> is added to vmlist at __get_vm_area_node() and then, some fields of
>> vm_struct such as nr_pages and pages are set at __vmalloc_area_node(). In
>> other words, it is added to vmlist before it is fully initialized. At the
>> same time, when the /proc/vmallocinfo is read, it accesses the pages field
>> of vm_struct according to the nr_pages field at show_numa_info(). Thus, a
>> null pointer access happens.
>>
>> Patch:
>> This patch adds newly allocated vm_struct to the vmlist *after* it is fully
>> initialized. So, it can avoid accessing the pages field with unallocated
>> page when show_numa_info() is called.
> 
> Seems rather ugly, but I guess it's OK.  vmalloc() is "special" in that
> it fills the area with allocated pages, whereas all the
> get_vm_area()-type callers don't do that.
> 
>>
>> ...
>>
>> @@ -1381,17 +1403,20 @@ struct vm_struct *remove_vm_area(const void *addr)
>>  	va = find_vmap_area((unsigned long)addr);
>>  	if (va && va->flags & VM_VM_AREA) {
>>  		struct vm_struct *vm = va->private;
>> -		struct vm_struct *tmp, **p;
>> -		/*
>> -		 * remove from list and disallow access to this vm_struct
>> -		 * before unmap. (address range confliction is maintained by
>> -		 * vmap.)
>> -		 */
>> -		write_lock(&vmlist_lock);
>> -		for (p = &vmlist; (tmp = *p) != vm; p = &tmp->next)
>> -			;
>> -		*p = tmp->next;
>> -		write_unlock(&vmlist_lock);
>> +
>> +		if (!(vm->flags & VM_UNLIST)) {
>> +			struct vm_struct *tmp, **p;
>> +			/*
>> +			 * remove from list and disallow access to
>> +			 * this vm_struct before unmap. (address range
>> +			 * confliction is maintained by vmap.)
>> +			 */
>> +			write_lock(&vmlist_lock);
>> +			for (p = &vmlist; (tmp = *p) != vm; p = &tmp->next)
>> +				;
>> +			*p = tmp->next;
>> +			write_unlock(&vmlist_lock);
>> +		}
> 
> Is this needed?  How can remove_vm_area() actually be called with a
> VM_UNLIST area?
> 

Yes, it is needed because this patch does not add the newly allocated vm_struct
to vmlist at __get_vm_area_node(). So, revove_vm_area() with unlisted vm_struct
will be called when an error occurs within __vmalloc_area_node(). 

> 
> I think I'll let this patch cook in linux-next for a while and shall
> tag it for backporting into 3.1.x later on.
> 

I see, thank you. 

WARNING: multiple messages have this Message-ID (diff)
From: HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	yrl.pp-manager.tt@hitachi.com,
	David Rientjes <rientjes@google.com>,
	Namhyung Kim <namhyung@gmail.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH -v3] avoid null pointer access in vm_struct
Date: Wed, 24 Aug 2011 13:29:38 +0900	[thread overview]
Message-ID: <4E547E32.4030001@hitachi.com> (raw)
In-Reply-To: <20110822152505.22b58998.akpm@linux-foundation.org>

Hi Andrew,

(2011/08/23 7:25), Andrew Morton wrote:
> On Sun, 21 Aug 2011 17:21:32 +0900
> Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> wrote:
> 
>> The /proc/vmallocinfo shows information about vmalloc allocations in vmlist
>> that is a linklist of vm_struct. It, however, may access pages field of
>> vm_struct where a page was not allocated. This results in a null pointer
>> access and leads to a kernel panic.
>>
>> Why this happen:
>> In __vmalloc_node_range() called from vmalloc(), newly allocated vm_struct
>> is added to vmlist at __get_vm_area_node() and then, some fields of
>> vm_struct such as nr_pages and pages are set at __vmalloc_area_node(). In
>> other words, it is added to vmlist before it is fully initialized. At the
>> same time, when the /proc/vmallocinfo is read, it accesses the pages field
>> of vm_struct according to the nr_pages field at show_numa_info(). Thus, a
>> null pointer access happens.
>>
>> Patch:
>> This patch adds newly allocated vm_struct to the vmlist *after* it is fully
>> initialized. So, it can avoid accessing the pages field with unallocated
>> page when show_numa_info() is called.
> 
> Seems rather ugly, but I guess it's OK.  vmalloc() is "special" in that
> it fills the area with allocated pages, whereas all the
> get_vm_area()-type callers don't do that.
> 
>>
>> ...
>>
>> @@ -1381,17 +1403,20 @@ struct vm_struct *remove_vm_area(const void *addr)
>>  	va = find_vmap_area((unsigned long)addr);
>>  	if (va && va->flags & VM_VM_AREA) {
>>  		struct vm_struct *vm = va->private;
>> -		struct vm_struct *tmp, **p;
>> -		/*
>> -		 * remove from list and disallow access to this vm_struct
>> -		 * before unmap. (address range confliction is maintained by
>> -		 * vmap.)
>> -		 */
>> -		write_lock(&vmlist_lock);
>> -		for (p = &vmlist; (tmp = *p) != vm; p = &tmp->next)
>> -			;
>> -		*p = tmp->next;
>> -		write_unlock(&vmlist_lock);
>> +
>> +		if (!(vm->flags & VM_UNLIST)) {
>> +			struct vm_struct *tmp, **p;
>> +			/*
>> +			 * remove from list and disallow access to
>> +			 * this vm_struct before unmap. (address range
>> +			 * confliction is maintained by vmap.)
>> +			 */
>> +			write_lock(&vmlist_lock);
>> +			for (p = &vmlist; (tmp = *p) != vm; p = &tmp->next)
>> +				;
>> +			*p = tmp->next;
>> +			write_unlock(&vmlist_lock);
>> +		}
> 
> Is this needed?  How can remove_vm_area() actually be called with a
> VM_UNLIST area?
> 

Yes, it is needed because this patch does not add the newly allocated vm_struct
to vmlist at __get_vm_area_node(). So, revove_vm_area() with unlisted vm_struct
will be called when an error occurs within __vmalloc_area_node(). 

> 
> I think I'll let this patch cook in linux-next for a while and shall
> tag it for backporting into 3.1.x later on.
> 

I see, thank you. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-08-24  4:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-21  8:21 [PATCH -v3] avoid null pointer access in vm_struct Mitsuo Hayasaka
2011-08-21  8:21 ` Mitsuo Hayasaka
2011-08-22 22:25 ` Andrew Morton
2011-08-22 22:25   ` Andrew Morton
2011-08-24  4:29   ` HAYASAKA Mitsuo [this message]
2011-08-24  4:29     ` HAYASAKA Mitsuo
2011-08-24 15:58 ` Wanlong Gao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E547E32.4030001@hitachi.com \
    --to=mitsuo.hayasaka.hu@hitachi.com \
    --cc=akpm@linux-foundation.org \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=namhyung@gmail.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rientjes@google.com \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.