linux-kernel - Re: [PATCH 17/18] udf: prevent bounds-check bypass via speculative execution

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, 8 Jan 2018 11:20:25 +0100
From:   Jan Kara <jack@...e.cz>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        gregkh@...uxfoundation.org, peterz@...radead.org,
        netdev@...r.kernel.org, Jan Kara <jack@...e.com>,
        tglx@...utronix.de, torvalds@...ux-foundation.org,
        Elena Reshetova <elena.reshetova@...el.com>,
        alan@...ux.intel.com
Subject: Re: [PATCH 17/18] udf: prevent bounds-check bypass via speculative
 execution

On Fri 05-01-18 17:11:26, Dan Williams wrote:
> Static analysis reports that 'eahd->appAttrLocation' and
> 'eahd->impAttrLocation' may be a user controlled values that are used as
> data dependencies for calculating source and destination buffers for
> memmove operations. In order to avoid potential leaks of kernel memory
> values, block speculative execution of the instruction stream that could
> issue further reads based on invalid 'aal' or 'ial' values.
> 
> Based on an original patch by Elena Reshetova.
> 
> Cc: Jan Kara <jack@...e.com>
> Signed-off-by: Elena Reshetova <elena.reshetova@...el.com>
> Signed-off-by: Dan Williams <dan.j.williams@...el.com>

Umm, so I fail to see the user controlled input here.
udf_add_extendedattr() is called from a single place - udf_update_inode()
- and there all arguments except 'inode' are constant AFAICS. Also it gets
called only when block device or character device inode is created - that
already limits the possible user influence a lot since generally normal
users are not allowed to do that.

If the static checker is concerned that the inode contents is to some extent
user controllable, it is right but:
a) In this particular case udf_add_extendedattr() can get executed only on
freshly created inode so values are controlled by the kernel.
b) Even if in future we'd call udf_add_extendedattr() on inode loaded from
disk we do sanitycheck i_lenEAttr in udf_read_inode() when loading the value
from disk. And that would generally be way before we get to functions adding
extended attributes to the inode...

So overall I don't think this patch is needed.

								Honza

> diff --git a/fs/udf/misc.c b/fs/udf/misc.c
> index 401e64cde1be..9403160822de 100644
> --- a/fs/udf/misc.c
> +++ b/fs/udf/misc.c
> @@ -51,6 +51,8 @@ struct genericFormat *udf_add_extendedattr(struct inode *inode, uint32_t size,
>  	int offset;
>  	uint16_t crclen;
>  	struct udf_inode_info *iinfo = UDF_I(inode);
> +	uint8_t *ea_dst, *ea_src;
> +	uint32_t aal, ial;
>  
>  	ea = iinfo->i_ext.i_data;
>  	if (iinfo->i_lenEAttr) {
> @@ -100,33 +102,34 @@ struct genericFormat *udf_add_extendedattr(struct inode *inode, uint32_t size,
>  
>  		offset = iinfo->i_lenEAttr;
>  		if (type < 2048) {
> -			if (le32_to_cpu(eahd->appAttrLocation) <
> -					iinfo->i_lenEAttr) {
> -				uint32_t aal =
> -					le32_to_cpu(eahd->appAttrLocation);
> -				memmove(&ea[offset - aal + size],
> -					&ea[aal], offset - aal);
> +			aal = le32_to_cpu(eahd->appAttrLocation);
> +			if ((ea_dst = nospec_array_ptr(ea, offset - aal + size,
> +						       iinfo->i_lenEAttr)) &&
> +			    (ea_src = nospec_array_ptr(ea, aal,
> +						       iinfo->i_lenEAttr))) {
> +				memmove(ea_dst, ea_src, offset - aal);
>  				offset -= aal;
>  				eahd->appAttrLocation =
>  						cpu_to_le32(aal + size);
>  			}
> -			if (le32_to_cpu(eahd->impAttrLocation) <
> -					iinfo->i_lenEAttr) {
> -				uint32_t ial =
> -					le32_to_cpu(eahd->impAttrLocation);
> -				memmove(&ea[offset - ial + size],
> -					&ea[ial], offset - ial);
> +
> +			ial = le32_to_cpu(eahd->impAttrLocation);
> +			if ((ea_dst = nospec_array_ptr(ea, offset - ial + size,
> +						       iinfo->i_lenEAttr)) &&
> +			    (ea_src = nospec_array_ptr(ea, ial,
> +						       iinfo->i_lenEAttr))) {
> +				memmove(ea_dst, ea_src, offset - ial);
>  				offset -= ial;
>  				eahd->impAttrLocation =
>  						cpu_to_le32(ial + size);
>  			}
>  		} else if (type < 65536) {
> -			if (le32_to_cpu(eahd->appAttrLocation) <
> -					iinfo->i_lenEAttr) {
> -				uint32_t aal =
> -					le32_to_cpu(eahd->appAttrLocation);
> -				memmove(&ea[offset - aal + size],
> -					&ea[aal], offset - aal);
> +			aal = le32_to_cpu(eahd->appAttrLocation);
> +			if ((ea_dst = nospec_array_ptr(ea, offset - aal + size,
> +						       iinfo->i_lenEAttr)) &&
> +			    (ea_src = nospec_array_ptr(ea, aal,
> +						       iinfo->i_lenEAttr))) {
> +				memmove(ea_dst, ea_src, offset - aal);
>  				offset -= aal;
>  				eahd->appAttrLocation =
>  						cpu_to_le32(aal + size);
> 
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR