[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220901030610.1121299-1-keescook@chromium.org>
Date: Wed, 31 Aug 2022 20:06:08 -0700
From: Kees Cook <keescook@...omium.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Kees Cook <keescook@...omium.org>,
Pablo Neira Ayuso <pablo@...filter.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>,
syzbot <syzkaller@...glegroups.com>,
Yajun Deng <yajun.deng@...ux.dev>,
Oliver Hartkopp <socketcan@...tkopp.net>,
Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
linux-hardening@...r.kernel.org
Subject: [PATCH 0/2] netlink: Bounds-check struct nlmsgerr creation
Hi,
In order to avoid triggering the coming runtime memcpy() bounds checking,
the length of the destination needs to be "visible" to the compiler in
some way. However, netlink is constructed in a rather hidden fashion,
and my attempts to wrangle it have resulted in this series, which perform
explicit bounds checking before using unsafe_memcpy().
-Kees
Kees Cook (2):
netlink: Bounds-check nlmsg_len()
netlink: Bounds-check struct nlmsgerr creation
include/net/netlink.h | 10 ++++++-
net/netfilter/ipset/ip_set_core.c | 10 +++++--
net/netlink/af_netlink.c | 49 +++++++++++++++++++++----------
3 files changed, 49 insertions(+), 20 deletions(-)
--
2.34.1
Powered by blists - more mailing lists