On 2019/3/5 15:31, Steffen Klassert wrote:
On Tue, Mar 05, 2019 at 03:08:49PM +0800, Su Yanjun <suyj.f...@cn.fujitsu.com>
wrote:
On 2019/3/5 14:49, Herbert Xu wrote:
On Sun, Mar 03, 2019 at 10:47:39PM -0500, Su Yanjun wrote:
When i review xfrm_user.c code, i found some potentical bug in it.
In xfrm_user_rcvmsg if type parameter from user space is set to
XFRM_MSG_MAX or XFRM_MSG_NEWSADINFO or XFRM_MSG_NEWSPDINFO. It will cause
xfrm_user_rcv_msg referring to null entry in xfrm_dispatch array.
Signed-off-by: Su Yanjun <suyj.f...@cn.fujitsu.com>
---
net/xfrm/xfrm_user.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index a131f9f..d832783 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2630,11 +2630,13 @@ static int xfrm_user_rcv_msg(struct sk_buff *skb,
struct nlmsghdr *nlh,
return -EOPNOTSUPP;
type = nlh->nlmsg_type;
- if (type > XFRM_MSG_MAX)
+ if (type >= XFRM_MSG_MAX)
return -EINVAL;
Your patch is wrong. Please check the definition of XFRM_MSG_MAX.
I see, thanks for your reply.
type -= XFRM_MSG_BASE;
link = &xfrm_dispatch[type];
+ if (!link)
+ return -EOPNOTSUPP;
Here **link** may refer to null entry for special types such as
XFRM_MSG_MAX or XFRM_MSG_NEWSADINFO or XFRM_MSG_NEWSPDINFO
Am i miss something?
'link' is always a valid pointer into that array.
Thanks
Su
