[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220512123313.218063-1-imagedong@tencent.com>
Date: Thu, 12 May 2022 20:33:09 +0800
From: menglong8.dong@...il.com
To: kuba@...nel.org
Cc: nhorman@...driver.com, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, yoshfuji@...ux-ipv6.org, dsahern@...nel.org,
imagedong@...cent.com, kafai@...com, talalahmad@...gle.com,
keescook@...omium.org, asml.silence@...il.com, willemb@...gle.com,
vasily.averin@...ux.dev, ilias.apalodimas@...aro.org,
luiz.von.dentz@...el.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: [PATCH net-next v2 0/4] net: skb: check the boundrary of skb drop reason
From: Menglong Dong <imagedong@...cent.com>
In the commit 1330b6ef3313 ("skb: make drop reason booleanable"),
SKB_NOT_DROPPED_YET is added to the enum skb_drop_reason, which makes
the invalid drop reason SKB_NOT_DROPPED_YET can leak to the kfree_skb
tracepoint. Once this happen (it happened, as 4th patch says), it can
cause NULL pointer in drop monitor and result in kernel panic.
Therefore, check the boundrary of drop reason in both kfree_skb_reason
(2th patch) and drop monitor (1th patch) to prevent such case happens
again.
Meanwhile, fix the invalid drop reason passed to kfree_skb_reason() in
tcp_v4_rcv() and tcp_v6_rcv().
Changes since v1:
- consider tcp_v6_rcv() in the 4th patch
Menglong Dong (4):
net: dm: check the boundary of skb drop reasons
net: skb: check the boundrary of drop reason in kfree_skb_reason()
net: skb: change the definition SKB_DR_SET()
net: tcp: reset 'drop_reason' to NOT_SPCIFIED in tcp_v{4,6}_rcv()
include/linux/skbuff.h | 3 ++-
net/core/drop_monitor.c | 2 +-
net/core/skbuff.c | 5 +++++
net/ipv4/tcp_ipv4.c | 1 +
net/ipv6/tcp_ipv6.c | 1 +
5 files changed, 10 insertions(+), 2 deletions(-)
--
2.36.1
Powered by blists - more mailing lists