Change printf to puts to avoid a buffer overflow
PATCH 1/1 Change printf to puts to avoid a buffer overflow
printf as currently implemented in u-boot has a problem where it can overflow an internal buffer if it prints an expanded string that's too long. Our command lines are long enough to cause this problem. A fix should be coming, but in the mean time this change replaces a problematic printf with a few calls to puts that have the same effect. This may perform slightly better because it should avoid a copy and scanning for format specifiers. The amount of time it actually takes up is very tiny relative to everything else so in practice that's probably irrelevant.
--- arch/x86/lib/zimage.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
arch/x86/lib/zimage.c +3 -1
@@ -78,7 +78,9 @@ static void build_command_line(char *command_line, int auto_boot) } -printf ("Kernel command line: \"%s\"\n" , command_line); +puts ("Kernel command line: \"" ); +puts (command_line); +puts ("\"\n" ); } void *load_zimage(char *image, unsigned long kernel_size,
Signature · 1 line
1.7.3.1
PATCH 1/1 Change printf to puts to avoid a buffer overflow
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111108/bddbd63b/attachment.pgp
PATCH 1/1 Change printf to puts to avoid a buffer overflow
In reply to Gabe BlackHi Gabe,
Quoted 9 lines · Gabe Black
printf as currently implemented in u-boot has a problem where it can overflow an internal buffer if it prints an expanded string that's too long. Our command lines are long enough to cause this problem. A fix should be coming, but in the mean time this change replaces a problematic printf with a few calls to puts that have the same effect. This may perform slightly better because it should avoid a copy and scanning for format specifiers. The amount of time it actually takes up is very tiny relative to everything else so in practice that's probably irrelevant.
Quoted 4 lines
Signed-off-by Gabe Black <[email protected]>--- arch/x86/lib/zimage.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
Can you please rebase against u-boot-x86/master and re-submit
While you're at it, please change tag to 'x86:' style
Thanks,
Graeme
PATCH v2 1/1 x86: Change printf to puts to avoid a buffer overflow
printf as currently implemented in u-boot has a problem where it can overflow an internal buffer if it prints an expanded string that's too long. Our command lines are long enough to cause this problem. A fix should be coming, but in the mean time this change replaces a problematic printf with a few calls to puts that have the same effect. This may perform slightly better because it should avoid a copy and scanning for format specifiers. The amount of time it actually takes up is very tiny relative to everything else so in practice that's probably irrelevant.
---
Changes in v2:
- Rebase onto the x86 repository.
- Change the style of the summary tag.
arch/x86/lib/zimage.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
arch/x86/lib/zimage.c +3 -1
@@ -75,7 +75,9 @@ static void build_command_line(char *command_line, int auto_boot)if (env_command_line)strcat (command_line, env_command_line); -printf ("Kernel command line: \"%s\"\n" , command_line); +puts ("Kernel command line: \"" ); +puts (command_line); +puts ("\"\n" ); } void *load_zimage(char *image, unsigned long kernel_size,
Signature · 1 line
1.7.3.1
PATCH v2 1/1 x86: Change printf to puts to avoid a buffer overflow
Quoted 10 lines · Gabe Black
printf as currently implemented in u-boot has a problem where it can overflow an internal buffer if it prints an expanded string that's too long. Our command lines are long enough to cause this problem. A fix should be coming, but in the mean time this change replaces a problematic printf with a few calls to puts that have the same effect. This may perform slightly better because it should avoid a copy and scanning for format specifiers. The amount of time it actually takes up is very tiny relative to everything else so in practice that's probably irrelevant.
Signed-off-by Gabe Black <[email protected]>
Applied to u-boot-x86/master
Thanks,
Graeme