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  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:	Wed, 07 Oct 2015 10:07:33 -0400
From:	Sasha Levin <sasha.levin@...cle.com>
To:	Prarit Bhargava <prarit@...hat.com>,
	Bjorn Helgaas <helgaas@...nel.org>
CC:	bhelgaas@...gle.com, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: prevent out of bounds access in numa_node override

On 10/06/2015 04:02 PM, Prarit Bhargava wrote:
> 
> 
> On 10/06/2015 03:36 PM, Bjorn Helgaas wrote:
>> Hi Sasha,
>>
>> On Sun, Oct 04, 2015 at 05:49:29PM -0400, Sasha Levin wrote:
>>> Commit 63692df1 ("PCI: Allow numa_node override via sysfs") didn't check that
>>> the numa node provided by userspace is valid. Passing a node number too high
>>> would attempt to access invalid memory and trigger a kernel panic.
>>>
>>> Fixes: 63692df1 ("PCI: Allow numa_node override via sysfs")
>>> Signed-off-by: Sasha Levin <sasha.levin@...cle.com>
>>> ---
>>>  drivers/pci/pci-sysfs.c |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
>>> index 312f23a..e9abca8 100644
>>> --- a/drivers/pci/pci-sysfs.c
>>> +++ b/drivers/pci/pci-sysfs.c
>>> @@ -216,7 +216,7 @@ static ssize_t numa_node_store(struct device *dev,
>>>  	if (ret)
>>>  		return ret;
>>>  
>>> -	if (!node_online(node))
>>> +	if (node > MAX_NUMNODES || !node_online(node))
>>
>> This needs to be "node >= MAX_NUMNODES", doesn't it?  I'll fix it up if
>> you agree.

Yup, you're right.

> 
> Not a strenuous objection, but I don't see much bound checking using
> MAX_NUMNODES in the kernel outside of the core numa area.  Is fixing
> node_online() with bounds checking a better option here so that other callers
> get the fix?  I would have thought that calling node_online() with node >
> MAX_NUMNODES should be safe to call.

I don't know, this will add overhead to node_online(), and isn't really
done in any other similar function. For example, cpu_online() isn't safe
to call with cpu > NR_CPUS either.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists