linux-kernel - Re: [PATCH] media: v4l: subdev: Prevent NULL routes access

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: <0ff25743-30c6-4c26-955f-c4c26578ebb6@ideasonboard.com>
Date: Mon, 25 Nov 2024 13:33:15 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>,
 Cosmin Tanislav <demonsingur@...il.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>,
 Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
 Hans Verkuil <hverkuil@...all.nl>, Paweł Anikiel
 <panikiel@...gle.com>, linux-media@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: v4l: subdev: Prevent NULL routes access

Hi,

On 25/11/2024 10:39, Sakari Ailus wrote:
> Hi Cosmin,
> 
> Thanks for the patch.
> 
> On Fri, Nov 22, 2024 at 04:37:12PM +0200, Cosmin Tanislav wrote:
>> When using v4l2_subdev_set_routing to set a subdev's routing, and the
>> passed routing.num_routes is 0, kmemdup is not called to populate the
>> routes of the new routing (which is fine, since we wouldn't want to pass
>> a possible NULL value to kmemdup).
>>
>> This results in subdev's routing.routes to be NULL.
>>
>> routing.routes is further used in some places without being guarded by
>> the same num_routes non-zero condition.
>>
>> Fix it.
> 
> While I think moving the code to copy the routing table seems reasonable,
> is there a need to make num_routes == 0 a special case? No memcpy()
> implementation should access destination or source if the size is 0.

I think so too, but Cosmin convinced me that the spec says otherwise.

 From the C spec I have, in "7.21.1 String function conventions":

"
Where an argument declared as size_t n specifies the length of the array 
for a
function, n can have the value zero on a call to that function. Unless 
explicitly stated
otherwise in the description of a particular function in this subclause, 
pointer arguments
on such a call shall still have valid values, as described in 7.1.4.
"

The memcpy section has no explicit mention that would hint otherwise.

In 7.1.4 Use of library functions it says that unless explicitly stated 
otherwise, a null pointer is an invalid value.

That said, I would still consider memcpy() with size 0 always ok, 
regardless of the src or dst, as the only memcpy implementation we need 
to care about is the kernel's.

  Tomi