linux-kernel - Re: [patch] drm/amd: cleanup get_mfd_cell

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] [day] [month] [year] [list]

Message-ID: <56D185ED.3010906@bfs.de>
Date:	Sat, 27 Feb 2016 12:18:05 +0100
From:	walter harms <wharms@....de>
To:	Dan Carpenter <dan.carpenter@...cle.com>
CC:	David Airlie <airlied@...ux.ie>,
	Alex Deucher <alexander.deucher@....com>,
	Maruthi Srinivas Bayyavarapu <Maruthi.Bayyavarapu@....com>,
	Jammy Zhou <Jammy.Zhou@....com>,
	Murali Krishna Vemuri <murali-krishna.vemuri@....com>,
	Chunming Zhou <david1.zhou@....com>,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	kernel-janitors@...r.kernel.org
Subject: Re: [patch] drm/amd: cleanup get_mfd_cell_dev()



Am 27.02.2016 11:40, schrieb Dan Carpenter:
> On Sat, Feb 27, 2016 at 10:50:40AM +0100, walter harms wrote:
>>
>>
>> Am 25.02.2016 08:47, schrieb Dan Carpenter:
>>> It's simpler to just use snprintf() to print this to one buffer instead
>>> of using strcpy() and strcat().  Also using snprintf() is slightly safer
>>> than using sprintf().
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@...cle.com>
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
>>> index 9f8cfaa..d6b0bff 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
>>> @@ -240,12 +240,10 @@ static int acp_poweron(struct generic_pm_domain *genpd)
>>>  static struct device *get_mfd_cell_dev(const char *device_name, int r)
>>>  {
>>>  	char auto_dev_name[25];
>>> -	char buf[8];
>>>  	struct device *dev;
>>>  
>>> -	sprintf(buf, ".%d.auto", r);
>>> -	strcpy(auto_dev_name, device_name);
>>> -	strcat(auto_dev_name, buf);
>>> +	snprintf(auto_dev_name, sizeof(auto_dev_name),
>>> +		 "%s.%d.auto", device_name, r);
>>>  	dev = bus_find_device_by_name(&platform_bus_type, NULL, auto_dev_name);
>>>  	dev_info(dev, "device %s added to pm domain\n", auto_dev_name);
>>>  
>>
>> hi,
>> i tried to understand what is the base for char auto_dev_name[25]. It is not clear
>> from these snipped if that is large or small.
>>
>> (To be aware i assume that
>> get_mfd_cell_dev("terrible_long_and_Stupid_name",1234567899346712) will never happen
>> but i could find no reason)
>>
>> A small comment that explains the magic 25 would be nice.
> 
> I have no idea, either of course.  For example,
> mc13xxx_add_subdevice_pdata() assumes device_name by itself can be 30
> characters.  Hence the change to snprintf.
> 

Hi Dan,
i also think that this limit is artificial, one of those "it works" things.
The problem is that i have seen changes in the naming als ready done, like the
shift from /dev/sda to things like /dev/disk/by-id/scsi-SATA_WDC_WD5000AAKS-_WD-WCASY5869245-part1
and you are out of the game here. snprintf will cut the tail and the %d.auto stuff is dead in the water.
To make it clear, I do not thing that is security related issue but it could result in annoying
failures. (the solution is obviously to use asprintf() and free the mem later :) ).

re,
 wh