Skip to contentSkip to conversation

video/logo: fix use logo after free prevention

PATCH In review Manfred Schlaegl 2 participants 2 messages Apr 17, 2015 Framebuffer layer

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 video/logo: fix use logo after free prevention

After 92b004d1aa9f367c372511ca0330f58216b25703 the logos disappeared on Freescale i.MX53 and i.MX6 SoC's (detected on linux-3.12.37). This happens because the fb_find_logo function is validly called (initdata still not freed) AFTER newly introduced latecall fb_logo_late_init.

Instead of stetting a logos_freed flag somewhere in lateinit, this patch uses system_state=SYSTEM_BOOTING as indication for valid initdata.

---
 drivers/video/logo/logo.c |   21 +++++----------------
 1 file changed, 5 insertions(+), 16 deletions(-)
drivers/video/logo/logo.c +5 -16
index 10fbfd8..ad37561 100644
@@ -21,21 +21,6 @@ static bool nologo;
 module_param(nologo, bool, 0);
 MODULE_PARM_DESC(nologo, "Disables startup logo");
 
-/*
- * Logos are located in the initdata, and will be freed in kernel_init.
- * Use late_init to mark the logos as freed to prevent any further use.
- */
-
-static bool logos_freed;
-
-static int __init fb_logo_late_init(void)
-{
-	logos_freed = true;
-	return 0;
-}
-
-late_initcall(fb_logo_late_init);
-
 /* logo's are marked __initdata. Use __init_refok to tell
  * modpost that it is intended that this function uses data
  * marked __initdata.
@@ -44,7 +29,11 @@ const struct linux_logo * __init_refok fb_find_logo(int depth)
 {
 	const struct linux_logo *logo = NULL;
 
-	if (nologo || logos_freed)
+	/*
+	 * Logos are located in the initdata, and will be freed in kernel_init.
+	 * Use system_state to determine, if initdata is still useable.
+	 */
+	if (nologo || system_state != SYSTEM_BOOTING)
 		return NULL;
 
 	if (depth >= 1) {
Signature · 1 line
1.7.10.4
#1 lore raw

Hi,

Quoted 8 lines · Manfred Schlaegl

After 92b004d1aa9f367c372511ca0330f58216b25703 the logos disappeared on Freescale i.MX53 and i.MX6 SoC's (detected on linux-3.12.37). This happens because the fb_find_logo function is validly called (initdata still not freed) AFTER newly introduced latecall fb_logo_late_init.

Instead of stetting a logos_freed flag somewhere in lateinit, this patch uses system_state=SYSTEM_BOOTING as indication for valid initdata.

The kernel init does free_initmem() call before setting the system_state to SYSTEM_RUNNING, so there's a period of time when the logos are freed, but the check in you patch does not catch it.

Tomi