All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH] splash: Prevent splash_load_fs from writing to 0x0
@ 2017-02-24 16:46 Jonathan Golder
  2017-02-26  7:05 ` Igor Grinberg
  2017-02-27 15:14 ` Anatolij Gustschin
  0 siblings, 2 replies; 4+ messages in thread
From: Jonathan Golder @ 2017-02-24 16:46 UTC (permalink / raw)
  To: u-boot

Passing NULL to fs_read() for actread value results in hanging U-Boot
at least on our ARM plattform (TI AM335x). Since fs_read() and
following functions do not catch nullpointers, writing to 0x0 occurs.

Passing a local dummy var instead of NULL solves this issue.

Signed-off-by: Jonathan Golder <jonathan.golder@kurz-elektronik.de>
Cc: Anatolij Gustschin <agust@denx.de>
---
 common/splash_source.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/common/splash_source.c b/common/splash_source.c
index a5eeb3f..d1647c8 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -216,6 +216,7 @@ static int splash_load_fs(struct splash_location *location, u32 bmp_load_addr)
 {
 	int res = 0;
 	loff_t bmp_size;
+	loff_t actread;
 	char *splash_file;
 
 	splash_file = getenv("splashfile");
@@ -251,7 +252,7 @@ static int splash_load_fs(struct splash_location *location, u32 bmp_load_addr)
 	}
 
 	splash_select_fs_dev(location);
-	res = fs_read(splash_file, bmp_load_addr, 0, 0, NULL);
+	res = fs_read(splash_file, bmp_load_addr, 0, 0, &actread);
 
 out:
 	if (location->ubivol != NULL)
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [U-Boot] [PATCH] splash: Prevent splash_load_fs from writing to 0x0
  2017-02-24 16:46 [U-Boot] [PATCH] splash: Prevent splash_load_fs from writing to 0x0 Jonathan Golder
@ 2017-02-26  7:05 ` Igor Grinberg
       [not found]   ` <48FA4BE8-665C-4076-AB5E-683CF747839D@kurz-elektronik.de>
  2017-02-27 15:14 ` Anatolij Gustschin
  1 sibling, 1 reply; 4+ messages in thread
From: Igor Grinberg @ 2017-02-26  7:05 UTC (permalink / raw)
  To: u-boot

Hi Jonathan,

On 02/24/17 18:46, Jonathan Golder wrote:
> Passing NULL to fs_read() for actread value results in hanging U-Boot
> at least on our ARM plattform (TI AM335x). Since fs_read() and
> following functions do not catch nullpointers, writing to 0x0 occurs.
> 
> Passing a local dummy var instead of NULL solves this issue.

I haven't looked at fs_read() yet, but from the above it seems
that a better approach would be to fix the fs_read()?
Might there be use cases when it is legitimate to pass NULL?

> 
> Signed-off-by: Jonathan Golder <jonathan.golder@kurz-elektronik.de>
> Cc: Anatolij Gustschin <agust@denx.de>
> ---
>  common/splash_source.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/common/splash_source.c b/common/splash_source.c
> index a5eeb3f..d1647c8 100644
> --- a/common/splash_source.c
> +++ b/common/splash_source.c
> @@ -216,6 +216,7 @@ static int splash_load_fs(struct splash_location *location, u32 bmp_load_addr)
>  {
>  	int res = 0;
>  	loff_t bmp_size;
> +	loff_t actread;
>  	char *splash_file;
>  
>  	splash_file = getenv("splashfile");
> @@ -251,7 +252,7 @@ static int splash_load_fs(struct splash_location *location, u32 bmp_load_addr)
>  	}
>  
>  	splash_select_fs_dev(location);
> -	res = fs_read(splash_file, bmp_load_addr, 0, 0, NULL);
> +	res = fs_read(splash_file, bmp_load_addr, 0, 0, &actread);
>  
>  out:
>  	if (location->ubivol != NULL)
> 

-- 
Regards,
Igor.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot] [PATCH] splash: Prevent splash_load_fs from writing to 0x0
       [not found]   ` <48FA4BE8-665C-4076-AB5E-683CF747839D@kurz-elektronik.de>
@ 2017-02-27 11:13     ` Igor Grinberg
  0 siblings, 0 replies; 4+ messages in thread
From: Igor Grinberg @ 2017-02-27 11:13 UTC (permalink / raw)
  To: u-boot

Hi Jonathan,

On 02/27/17 10:10, Jonathan Golder wrote:
> Hi Igor,
> 
>> I haven't looked at fs_read() yet, but from the above it seems that
>> a better approach would be to fix the fs_read()? Might there be use
>> cases when it is legitimate to pass NULL?
> 
> 
> Well, actually I have not dived into the depths of the fs_read ()
> deeper than realising that something went wrong.
> 
> Before posting this patch I greped for usages of fs_read() with NULL
> as last parameter and found only this occurrence. So I supposed that
> passing NULL for actread is not an intended use case of fs_read ().

Probably, yet this use case appeared and correct me if I'm wrong,
the splash source code does not really care of that parameter, and
it wants to use the fs_read().
So maybe the problem is in fs_read() API not covering a legitimate
use case?
Of course this patch will fix the problem by hiding it till next time.

-- 
Regards,
Igor.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [U-Boot] [PATCH] splash: Prevent splash_load_fs from writing to 0x0
  2017-02-24 16:46 [U-Boot] [PATCH] splash: Prevent splash_load_fs from writing to 0x0 Jonathan Golder
  2017-02-26  7:05 ` Igor Grinberg
@ 2017-02-27 15:14 ` Anatolij Gustschin
  1 sibling, 0 replies; 4+ messages in thread
From: Anatolij Gustschin @ 2017-02-27 15:14 UTC (permalink / raw)
  To: u-boot

On Fri, 24 Feb 2017 17:46:10 +0100
Jonathan Golder jonathan.golder at kurz-elektronik.de wrote:

> Passing NULL to fs_read() for actread value results in hanging U-Boot
> at least on our ARM plattform (TI AM335x). Since fs_read() and
> following functions do not catch nullpointers, writing to 0x0 occurs.
> 
> Passing a local dummy var instead of NULL solves this issue.
> 
> Signed-off-by: Jonathan Golder <jonathan.golder@kurz-elektronik.de>
> Cc: Anatolij Gustschin <agust@denx.de>
> ---
>  common/splash_source.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

applied to u-boot-video/master, thanks!

--
Anatolij

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-02-27 15:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-24 16:46 [U-Boot] [PATCH] splash: Prevent splash_load_fs from writing to 0x0 Jonathan Golder
2017-02-26  7:05 ` Igor Grinberg
     [not found]   ` <48FA4BE8-665C-4076-AB5E-683CF747839D@kurz-elektronik.de>
2017-02-27 11:13     ` Igor Grinberg
2017-02-27 15:14 ` Anatolij Gustschin

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.