linux-kernel - Re: [PATCH] vt: initialize con_driver->node in con

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] [day] [month] [year] [list]

Date:	Tue, 11 Feb 2014 08:49:38 +0800
From:	Wang YanQing <udknight@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	jslaby@...e.cz, airlied@...hat.com, akpm@...ux-foundation.org,
	kilobyte@...band.pl, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] vt: initialize con_driver->node in con_init

On Fri, Feb 07, 2014 at 08:45:00AM -0800, Greg KH wrote:
> On Mon, Dec 30, 2013 at 11:11:02AM +0800, Wang YanQing wrote:
> > Commit 6db4063c5b72b46e9793b0f141a7a3984ac6facf
> > ("[PATCH] VT binding: Add sysfs control to the VT layer")
> > add node item into struct con_driver.
> 
> That commit was almost a decade ago, is this patch really needed?
> 
> > This patch initialize con_driver->node in con_init.
> 
> You are saying what it does, not _why_ it is needed or why this change
> is happening.
> 
> Please rewrite this with more information because as-is, I have no idea
> why I should accept this patch.

This patch meet the same situation with another patch I sended
("[PATCH v2]vt: fix potential dual con_driver register for conswitchp"),
if conswitchp in con_init is always the first con_driver we register, 
then no problem will happen due to node will be initialized to zero.

But if it isn't the first, we get trouble due to use uninitialized value 
of con_driver->node.

At least the code in con_init is not perfect, if we make sure con_driver
is always the first con_driver, then we don't need for(;;), just use
registered_con_driver[0] is enough.

Ok, if this two patches really don't fix any problem, it will protect you
from seeing *the same uselss patches* in your inbox again at least I think:).

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/