Skip to contentSkip to conversation

Change printf to puts to avoid a buffer overflow

PATCH Superseded Gabe Black 3 participants 5 messages Nov 8, 2011 – Nov 13, 2011 x86

lore
Share & tools
lore

Gabe Black

author
#0 lore raw

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
index d2dd6fd..a48ae6c 100644
@@ -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
#2 lore raw

PATCH 1/1 Change printf to puts to avoid a buffer overflow

In reply to Gabe Black

Hi 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
---
 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

author
#3 lore raw

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
index 8b42b5c..6843ff6 100644
@@ -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
#4 lore raw

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.

Applied to u-boot-x86/master

Thanks,

Graeme