linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH] [v2] pnp: acpi: fix fortify warning
Date: Thu, 30 Nov 2023 15:29:10 -0800	[thread overview]
Message-ID: <202311301528.EC95F51@keescook> (raw)
In-Reply-To: <20231128025411.141602-1-dmantipov@yandex.ru>

On Tue, Nov 28, 2023 at 05:52:10AM +0300, Dmitry Antipov wrote:
> When compiling with gcc version 14.0.0 20231126 (experimental)
> and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
> 
> In file included from ./include/linux/string.h:295,
>                  from ./include/linux/bitmap.h:12,
>                  from ./include/linux/cpumask.h:12,
>                  from ./arch/x86/include/asm/paravirt.h:17,
>                  from ./arch/x86/include/asm/cpuid.h:62,
>                  from ./arch/x86/include/asm/processor.h:19,
>                  from ./arch/x86/include/asm/cpufeature.h:5,
>                  from ./arch/x86/include/asm/thread_info.h:53,
>                  from ./include/linux/thread_info.h:60,
>                  from ./arch/x86/include/asm/preempt.h:9,
>                  from ./include/linux/preempt.h:79,
>                  from ./include/linux/spinlock.h:56,
>                  from ./include/linux/mmzone.h:8,
>                  from ./include/linux/gfp.h:7,
>                  from ./include/linux/slab.h:16,
>                  from ./include/linux/resource_ext.h:11,
>                  from ./include/linux/acpi.h:13,
>                  from drivers/pnp/pnpacpi/rsparser.c:11:
> In function 'fortify_memcpy_chk',
>     inlined from 'pnpacpi_parse_allocated_vendor' at drivers/pnp/pnpacpi/rsparser.c:158:3,
>     inlined from 'pnpacpi_allocated_resource' at drivers/pnp/pnpacpi/rsparser.c:249:3:
> ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field'
> declared with attribute warning: detected read beyond size of field (2nd parameter);
> maybe use struct_group()? [-Wattribute-warning]
>   588 |                         __read_overflow2_field(q_size_field, size);
>       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> According to the comments in include/linux/fortify-string.h, 'memcpy()',
> 'memmove()' and 'memset()' must not be used beyond individual struct
> members to ensure that the compiler can enforce protection against
> buffer overflows, and, IIUC, this also applies to partial copies from
> the particular member ('vendor->byte_data' in this case). So it should
> be better (and safer) to do both copies at once (and 'byte_data' of
> 'struct acpi_resource_vendor_typed' seems to be a good candidate for
> '__counted_by(byte_length)' as well).
> 
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> ---
> v2: prefer sizeof(range) over hardcoded constant (Rafael J. Wysocki)

Yeah, this looks good to me. Thanks for the fix!

Reviewed-by: Kees Cook <keescook@chromium.org>

-Kees

> ---
>  drivers/pnp/pnpacpi/rsparser.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pnp/pnpacpi/rsparser.c b/drivers/pnp/pnpacpi/rsparser.c
> index 4f05f610391b..c02ce0834c2c 100644
> --- a/drivers/pnp/pnpacpi/rsparser.c
> +++ b/drivers/pnp/pnpacpi/rsparser.c
> @@ -151,13 +151,13 @@ static int vendor_resource_matches(struct pnp_dev *dev,
>  static void pnpacpi_parse_allocated_vendor(struct pnp_dev *dev,
>  				    struct acpi_resource_vendor_typed *vendor)
>  {
> -	if (vendor_resource_matches(dev, vendor, &hp_ccsr_uuid, 16)) {
> -		u64 start, length;
> +	struct { u64 start, length; } range;
>  
> -		memcpy(&start, vendor->byte_data, sizeof(start));
> -		memcpy(&length, vendor->byte_data + 8, sizeof(length));
> -
> -		pnp_add_mem_resource(dev, start, start + length - 1, 0);
> +	if (vendor_resource_matches(dev, vendor, &hp_ccsr_uuid,
> +				    sizeof(range))) {
> +		memcpy(&range, vendor->byte_data, sizeof(range));
> +		pnp_add_mem_resource(dev, range.start, range.start +
> +				     range.length - 1, 0);
>  	}
>  }
>  
> -- 
> 2.43.0
> 

-- 
Kees Cook

  reply	other threads:[~2023-11-30 23:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27 14:58 [PATCH] pnp: acpi: fix fortify warning Dmitry Antipov
2023-11-27 19:01 ` Rafael J. Wysocki
2023-11-28  2:52   ` [PATCH] [v2] " Dmitry Antipov
2023-11-30 23:29     ` Kees Cook [this message]
2023-12-06 20:03       ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202311301528.EC95F51@keescook \
    --to=keescook@chromium.org \
    --cc=dmantipov@yandex.ru \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).