linux-kernel - Re: [PATCH 1/3] init/main.c: introduce function ramdisk_exec

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

Date:   Mon, 24 May 2021 18:02:04 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     menglong8.dong@...il.com
Cc:     mcgrof@...nel.org, viro@...iv.linux.org.uk, keescook@...omium.org,
        samitolvanen@...gle.com, johan@...nel.org, ojeda@...nel.org,
        jeyu@...nel.org, joe@...ches.com, dong.menglong@....com.cn,
        masahiroy@...nel.org, jack@...e.cz, axboe@...nel.dk, hare@...e.de,
        gregkh@...uxfoundation.org, tj@...nel.org, song@...nel.org,
        neilb@...e.de, akpm@...ux-foundation.org, brho@...gle.com,
        f.fainelli@...il.com, wangkefeng.wang@...wei.com, arnd@...db.de,
        linux@...musvillemoes.dk, mhiramat@...nel.org, rostedt@...dmis.org,
        vbabka@...e.cz, glider@...gle.com, pmladek@...e.com,
        ebiederm@...ssion.com, jojing64@...il.com,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] init/main.c: introduce function ramdisk_exec_exist()

On Sat, May 22, 2021 at 07:31:53PM +0800, menglong8.dong@...il.com wrote:
> Introduce the function ramdisk_exec_exist, which is used to check
> the exist of 'ramdisk_execute_command'.
> 
> It can do absolute path and relative path check. For relative path,
> it will ignore '/' and '.' in the start of
> 'ramdisk_execute_command'.

> --- a/init/main.c
> +++ b/init/main.c
> @@ -1522,6 +1522,21 @@ void __init console_on_rootfs(void)
>  	fput(file);
>  }
>  
> +bool __init ramdisk_exec_exist(bool absolute)
> +{
> +	char *tmp_command = ramdisk_execute_command;
> +
> +	if (!tmp_command)
> +		return false;
> +
> +	if (!absolute) {
> +		while (*tmp_command == '/' || *tmp_command == '.')
> +			tmp_command++;

As far as I can tell, this will break if the user wants to use
".mybinary" or ".mydir/mybinary" as the name of their init program.

For that matter, it would break "...prog" or "...somedir/prog", which
would be strange but not something the kernel should prevent.

I don't think this code should be attempting to recreate
relative-to-absolute filename resolution.