netdev - Re: [PATCH net] net: netlink: prevent potential integer overflow in nlmsg

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]

Message-ID: <c428890e-1ad1-4602-9919-ba720546b821@stanley.mountain>
Date: Thu, 23 Jan 2025 08:48:34 +0300
From: Dan Carpenter <dan.carpenter@...aro.org>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: "David S. Miller" <davem@...emloft.net>, Thomas Graf <tgraf@...g.ch>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH net] net: netlink: prevent potential integer overflow in
 nlmsg_new()

On Wed, Jan 22, 2025 at 02:52:39PM +0100, Przemek Kitszel wrote:
> On 1/22/25 14:49, Dan Carpenter wrote:
> > The "payload" variable is type size_t, however the nlmsg_total_size()
> > function will a few bytes to it and then truncate the result to type
> > int.  That means that if "payload" is more than UINT_MAX the alloc_skb()
> 
> In the code it's INT_MAX, would be best to have the same used in both
> places (or explain it so it's obvious)
> 

Yeah.  It's not probably not obvious.

I don't like using UINT_MAX as a limit because why push so close to the
edge?  Normal allocation functions are capped at INT_MAX to avoid
integer overflows.  You'd have to use vmalloc() to allocate more than
2GB of RAM.  So it's not like we gain anything by using a higher, riskier
number.

The nlmsg_total_size() function adds potentially 19 bytes to the
payload.

INT_MAX plus anything less than 2 million number can't overflow to zero.
It could overflow to negative but you can't allocate negative bytes so
that's fine.

The vfs_read/write() functions use MAX_RW_COUNT to avoid integer
overflows.  That's basically INT_MAX - PAGE_SIZE.  There are quite
a few places like this in the kernel which assume small numbers like
sizeof() are generally going to return less than PAGE_SIZE.  Would
that be better to do this.  Then it couldn't overflow to negative.

regards,
dan carpenter

diff --git a/include/net/netlink.h b/include/net/netlink.h
index e015ffbed819..ceeea04fae4a 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -1015,6 +1015,9 @@ static inline struct nlmsghdr *nlmsg_put_answer(struct sk_buff *skb,
  */
 static inline struct sk_buff *nlmsg_new(size_t payload, gfp_t flags)
 {
+	/* Prevent integer overflow */
+	if (payload > INT_MAX - PAGE_SIZE)
+		return NULL;
 	return alloc_skb(nlmsg_total_size(payload), flags);
 }