Linux-Modules Archive on lore.kernel.org
 help / Atom feed
* [PATCH] Verify memory sizes on 32 bit systems.
@ 2018-07-30 19:01 Tobias Stoeckmann
  2018-08-03 21:07 ` Lucas De Marchi
  0 siblings, 1 reply; 5+ messages in thread
From: Tobias Stoeckmann @ 2018-07-30 19:01 UTC (permalink / raw)
  To: linux-modules

Large file system support is activated by default, which means that
on 32 bit systems, off_t is 64 bit in size.

Using st.st_size or any other 64 bit variable with mmap can lead to
integer truncation and therefore insufficient memory mapping.

Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
---
 libkmod/libkmod-file.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libkmod/libkmod-file.c b/libkmod/libkmod-file.c
index 5eeba6a..86f34c6 100644
--- a/libkmod/libkmod-file.c
+++ b/libkmod/libkmod-file.c
@@ -255,6 +255,8 @@ static int load_reg(struct kmod_file *file)
 		return -errno;
 
 	file->size = st.st_size;
+	if ((uintmax_t)st.st_size > (uintmax_t)SIZE_MAX)
+		return -EFBIG;
 	file->memory = mmap(NULL, file->size, PROT_READ, MAP_PRIVATE,
 			    file->fd, 0);
 	if (file->memory == MAP_FAILED)
-- 
2.13.2


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Verify memory sizes on 32 bit systems.
  2018-07-30 19:01 [PATCH] Verify memory sizes on 32 bit systems Tobias Stoeckmann
@ 2018-08-03 21:07 ` Lucas De Marchi
  2018-08-03 21:10   ` Tobias Stoeckmann
  0 siblings, 1 reply; 5+ messages in thread
From: Lucas De Marchi @ 2018-08-03 21:07 UTC (permalink / raw)
  To: Tobias Stoeckmann; +Cc: linux-modules

On Mon, Jul 30, 2018 at 12:02 PM Tobias Stoeckmann
<tobias@stoeckmann.org> wrote:
>
> Large file system support is activated by default, which means that
> on 32 bit systems, off_t is 64 bit in size.
>
> Using st.st_size or any other 64 bit variable with mmap can lead to
> integer truncation and therefore insufficient memory mapping.
>
> Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
> ---
>  libkmod/libkmod-file.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libkmod/libkmod-file.c b/libkmod/libkmod-file.c
> index 5eeba6a..86f34c6 100644
> --- a/libkmod/libkmod-file.c
> +++ b/libkmod/libkmod-file.c
> @@ -255,6 +255,8 @@ static int load_reg(struct kmod_file *file)
>                 return -errno;
>
>         file->size = st.st_size;
> +       if ((uintmax_t)st.st_size > (uintmax_t)SIZE_MAX)

why casting?

Lucas De Marchi

> +               return -EFBIG;
>         file->memory = mmap(NULL, file->size, PROT_READ, MAP_PRIVATE,
>                             file->fd, 0);
>         if (file->memory == MAP_FAILED)
> --
> 2.13.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-modules" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Lucas De Marchi

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Verify memory sizes on 32 bit systems.
  2018-08-03 21:07 ` Lucas De Marchi
@ 2018-08-03 21:10   ` Tobias Stoeckmann
  2018-08-03 21:33     ` Lucas De Marchi
  0 siblings, 1 reply; 5+ messages in thread
From: Tobias Stoeckmann @ 2018-08-03 21:10 UTC (permalink / raw)
  To: Lucas De Marchi; +Cc: linux-modules

On Fri, Aug 03, 2018 at 02:07:34PM -0700, Lucas De Marchi wrote:
> > +       if ((uintmax_t)st.st_size > (uintmax_t)SIZE_MAX)
> 
> why casting?

Without casting, a warning could be triggered on 64 bit systems,
because on these systems a signed 64 bit int (off_t) is compared
with an unsigned 64 bit int (size_t) which could never be larger.

Casting it to uintmax_t, which is at least 64 bits in size,
silences this error.

No technical reason beyond that.


Tobias

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Verify memory sizes on 32 bit systems.
  2018-08-03 21:10   ` Tobias Stoeckmann
@ 2018-08-03 21:33     ` Lucas De Marchi
  2018-08-03 21:51       ` Tobias Stoeckmann
  0 siblings, 1 reply; 5+ messages in thread
From: Lucas De Marchi @ 2018-08-03 21:33 UTC (permalink / raw)
  To: Tobias Stoeckmann; +Cc: linux-modules

On Fri, Aug 3, 2018 at 2:10 PM Tobias Stoeckmann <tobias@stoeckmann.org> wrote:
>
> On Fri, Aug 03, 2018 at 02:07:34PM -0700, Lucas De Marchi wrote:
> > > +       if ((uintmax_t)st.st_size > (uintmax_t)SIZE_MAX)
> >
> > why casting?
>
> Without casting, a warning could be triggered on 64 bit systems,
> because on these systems a signed 64 bit int (off_t) is compared
> with an unsigned 64 bit int (size_t) which could never be larger.
>
> Casting it to uintmax_t, which is at least 64 bits in size,
> silences this error.

so you are casting the *sign* away, ok. But casting only st.st_size
should suffice.

Lucas De Marchi

>
> No technical reason beyond that.
>
>
> Tobias



-- 
Lucas De Marchi

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] Verify memory sizes on 32 bit systems.
  2018-08-03 21:33     ` Lucas De Marchi
@ 2018-08-03 21:51       ` Tobias Stoeckmann
  0 siblings, 0 replies; 5+ messages in thread
From: Tobias Stoeckmann @ 2018-08-03 21:51 UTC (permalink / raw)
  To: Lucas De Marchi; +Cc: linux-modules

On Fri, Aug 03, 2018 at 02:33:51PM -0700, Lucas De Marchi wrote:
> so you are casting the *sign* away, ok. But casting only st.st_size
> should suffice.

I've just tried with some examples and I couldn't trigger the
warning which I have seen in other situations like this, i.e.
"always false due to limited range of data type".

If I cast the off_t to size_t, the compiler knows that it is not
possible that it could ever be larger than SIZE_MAX, optimizing
the block away. So I took uintmax_t.

But as long as there's no annoying warning, I am fine with just
casting st_size.


Tobias

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-30 19:01 [PATCH] Verify memory sizes on 32 bit systems Tobias Stoeckmann
2018-08-03 21:07 ` Lucas De Marchi
2018-08-03 21:10   ` Tobias Stoeckmann
2018-08-03 21:33     ` Lucas De Marchi
2018-08-03 21:51       ` Tobias Stoeckmann

Linux-Modules Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-modules/0 linux-modules/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-modules linux-modules/ https://lore.kernel.org/linux-modules \
		linux-modules@vger.kernel.org linux-modules@archiver.kernel.org
	public-inbox-index linux-modules


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-modules


AGPL code for this site: git clone https://public-inbox.org/ public-inbox