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]
Message-Id: <20240530130318.2a78c0797c352a4d38cfb2c1@linux-foundation.org>
Date: Thu, 30 May 2024 13:03:18 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: <hailong.liu@...o.com>
Cc: <urezki@...il.com>, <hch@...radead.org>, <lstoakes@...il.com>,
 <21cnbao@...il.com>, <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
 <xiang@...nel.org>, <guangye.yang@...iatek.com>,
 <zhaoyang.huang@...soc.com>, "Hailong . Liu" <liuhailong@...o.com>
Subject: Re: [RFC PATCH] mm/vmalloc: fix vbq->free breakage

On Thu, 30 May 2024 17:31:08 +0800 <hailong.liu@...o.com> wrote:

> From: "hailong.liu" <hailong.liu@...o.com>
> 
> The function xa_for_each() in _vm_unmap_aliases() loops through all
> vbs. However, since commit 062eacf57ad9 ("mm: vmalloc: remove a global
> vmap_blocks xarray") the vb from xarray may not be on the corresponding
> CPU vmap_block_queue. Consequently, purge_fragmented_block() might
> use the wrong vbq->lock to protect the free list, leading to vbq->free
> breakage.

What are the userspace-visible runtime effects of this change?

> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index d12a17fc0c17..869e7788a7d5 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2269,10 +2269,9 @@ static void _vm_unmap_aliases(unsigned long start, unsigned long end, int flush)
>  	for_each_possible_cpu(cpu) {
>  		struct vmap_block_queue *vbq = &per_cpu(vmap_block_queue, cpu);
>  		struct vmap_block *vb;
> -		unsigned long idx;
> 
>  		rcu_read_lock();
> -		xa_for_each(&vbq->vmap_blocks, idx, vb) {
> +		list_for_each_entry_rcu(vb, &vbq->free, free_list) {
>  			spin_lock(&vb->lock);
> 
>  			/*
> ---
> https://lore.kernel.org/all/20240530025144.1570865-1-zhaoyang.huang@unisoc.com/
> BTW, zhangyang also encounter the same issue, maybe revert commit not a
> better solution. we need a map to get vbq from vb.

That patch didn't describe the runtime effects either.

Folks, please always do this.  So that others can decide whether their
kernel needs the fix, and so that others can decide whether this fix
might address an issue which their users are reporting.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ