[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220616151603.GA4400@lxhi-065>
Date: Thu, 16 Jun 2022 17:16:03 +0200
From: Eugeniu Rosca <erosca@...adit-jv.com>
To: Roberto Sassu <roberto.sassu@...wei.com>
CC: <viro@...iv.linux.org.uk>, <linux-security-module@...r.kernel.org>,
<linux-integrity@...r.kernel.org>, <initramfs@...r.kernel.org>,
<linux-api@...r.kernel.org>, <linux-fsdevel@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <bug-cpio@....org>,
<zohar@...ux.vnet.ibm.com>, <silviu.vlasceanu@...wei.com>,
<dmitry.kasatkin@...wei.com>, <takondra@...co.com>,
<kamensky@...co.com>, <hpa@...or.com>, <arnd@...db.de>,
<rob@...dley.net>, <james.w.mcmechan@...il.com>,
<niveditas98@...il.com>, Eugeniu Rosca <erosca@...adit-jv.com>,
Eugeniu Rosca <roscaeugeniu@...il.com>
Subject: Re: [PATCH v4 3/3] gen_init_cpio: add support for file metadata
Hello Roberto,
On Do, Mai 23, 2019 at 02:18:03 +0200, Roberto Sassu wrote:
> This patch adds support for file metadata (only TYPE_XATTR metadata type).
> gen_init_cpio has been modified to read xattrs from files that will be
> added to the image and to include file metadata as separate files with the
> special name 'METADATA!!!'.
>
> This behavior can be selected by setting the desired file metadata type as
> value for CONFIG_INITRAMFS_FILE_METADATA.
>
> Signed-off-by: Roberto Sassu <roberto.sassu@...wei.com>
> ---
> usr/Kconfig | 8 +++
> usr/Makefile | 4 +-
> usr/gen_init_cpio.c | 137 ++++++++++++++++++++++++++++++++++++--
> usr/gen_initramfs_list.sh | 10 ++-
> 4 files changed, 150 insertions(+), 9 deletions(-)
>
> diff --git a/usr/gen_init_cpio.c b/usr/gen_init_cpio.c
[..]
> +static int write_xattrs(const char *path)
> +{
[..]
> + while (list_ptr < xattr_list + list_len) {
> + name_len = strlen(list_ptr);
PVS-Studio 7.19 reports at this line:
=> usr/gen_init_cpio.c 84 warn V769
=> The 'xattr_list' pointer in the 'xattr_list + list_len' expression could be nullptr.
=> In such case, resulting value will be senseless and it should not be used. Check lines: 84, 69.
I guess the finding is valid and it's due to the fact that
the malloc return value is not being checked/sanitized?
BR, Eugeniu.
Powered by blists - more mailing lists