| Message ID | 20190724093509.1676-1-baijiaju1990@gmail.com |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | David Miller |
| Headers | show |
| Series | net: key: af_key: Fix possible null-pointer dereferences in pfkey_send_policy_notify() | expand |
On Wed, Jul 24, 2019 at 05:35:09PM +0800, Jia-Ju Bai wrote: > In pfkey_send_policy_notify(), there is an if statement on line 3081 to > check whether xp is NULL: > if (xp && xp->type != XFRM_POLICY_TYPE_MAIN) > > When xp is NULL, it is used by key_notify_policy() on line 3090: > key_notify_policy(xp, ...) > pfkey_xfrm_policy2msg_prep(xp) -- line 2211 > pfkey_xfrm_policy2msg_size(xp) -- line 2046 > for (i=0; i<xp->xfrm_nr; i++) -- line 2026 > t = xp->xfrm_vec + i; -- line 2027 > key_notify_policy(xp, ...) > xp_net(xp) -- line 2231 > return read_pnet(&xp->xp_net); -- line 534 Please don't quote random code lines, explain the problem instead. > > Thus, possible null-pointer dereferences may occur. > > To fix these bugs, xp is checked before calling key_notify_policy(). > > These bugs are found by a static analysis tool STCheck written by us. > > Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> > --- > net/key/af_key.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/net/key/af_key.c b/net/key/af_key.c > index b67ed3a8486c..ced54144d5fd 100644 > --- a/net/key/af_key.c > +++ b/net/key/af_key.c > @@ -3087,6 +3087,8 @@ static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, const struc > case XFRM_MSG_DELPOLICY: > case XFRM_MSG_NEWPOLICY: > case XFRM_MSG_UPDPOLICY: > + if (!xp) > + break; I think this can not happen. Who sends one of these notifications without a pointer to the policy?
On 2019-07-26, at 11:45:14 +0200, Steffen Klassert wrote: > On Wed, Jul 24, 2019 at 05:35:09PM +0800, Jia-Ju Bai wrote: > > In pfkey_send_policy_notify(), there is an if statement on line 3081 > > to check whether xp is NULL: > > if (xp && xp->type != XFRM_POLICY_TYPE_MAIN) > > > > When xp is NULL, it is used by key_notify_policy() on line 3090: > > key_notify_policy(xp, ...) > > pfkey_xfrm_policy2msg_prep(xp) -- line 2211 > > pfkey_xfrm_policy2msg_size(xp) -- line 2046 > > for (i=0; i<xp->xfrm_nr; i++) -- line 2026 > > t = xp->xfrm_vec + i; -- line 2027 > > key_notify_policy(xp, ...) > > xp_net(xp) -- line 2231 > > return read_pnet(&xp->xp_net); -- line 534 > > Please don't quote random code lines, explain the problem instead. > > > > > Thus, possible null-pointer dereferences may occur. > > > > To fix these bugs, xp is checked before calling key_notify_policy(). > > > > These bugs are found by a static analysis tool STCheck written by > > us. > > > > Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> > > --- > > net/key/af_key.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/net/key/af_key.c b/net/key/af_key.c > > index b67ed3a8486c..ced54144d5fd 100644 > > --- a/net/key/af_key.c > > +++ b/net/key/af_key.c > > @@ -3087,6 +3087,8 @@ static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, const struc > > case XFRM_MSG_DELPOLICY: > > case XFRM_MSG_NEWPOLICY: > > case XFRM_MSG_UPDPOLICY: > > + if (!xp) > > + break; > > I think this can not happen. Who sends one of these notifications > without a pointer to the policy? I had a quick grep and found two places where km_policy_notify is passed NULL as the policy: $ grep -rn '\<km_policy_notify(NULL,' net/ net/xfrm/xfrm_user.c:2154: km_policy_notify(NULL, 0, &c); net/key/af_key.c:2788: km_policy_notify(NULL, 0, &c); They occur in xfrm_flush_policy() and pfkey_spdflush() respectively. J.
On Fri, Jul 26, 2019 at 09:15:55PM +0100, Jeremy Sowden wrote: > On 2019-07-26, at 11:45:14 +0200, Steffen Klassert wrote: > > On Wed, Jul 24, 2019 at 05:35:09PM +0800, Jia-Ju Bai wrote: > > > > > > diff --git a/net/key/af_key.c b/net/key/af_key.c > > > index b67ed3a8486c..ced54144d5fd 100644 > > > --- a/net/key/af_key.c > > > +++ b/net/key/af_key.c > > > @@ -3087,6 +3087,8 @@ static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, const struc > > > case XFRM_MSG_DELPOLICY: > > > case XFRM_MSG_NEWPOLICY: > > > case XFRM_MSG_UPDPOLICY: > > > + if (!xp) > > > + break; > > > > I think this can not happen. Who sends one of these notifications > > without a pointer to the policy? > > I had a quick grep and found two places where km_policy_notify is passed > NULL as the policy: > > $ grep -rn '\<km_policy_notify(NULL,' net/ > net/xfrm/xfrm_user.c:2154: km_policy_notify(NULL, 0, &c); > net/key/af_key.c:2788: km_policy_notify(NULL, 0, &c); > > They occur in xfrm_flush_policy() and pfkey_spdflush() respectively. Yes, but these two send a XFRM_MSG_FLUSHPOLICY notify. This does not trigger the code that is changed here.
diff --git a/net/key/af_key.c b/net/key/af_key.c index b67ed3a8486c..ced54144d5fd 100644 --- a/net/key/af_key.c +++ b/net/key/af_key.c @@ -3087,6 +3087,8 @@ static int pfkey_send_policy_notify(struct xfrm_policy *xp, int dir, const struc case XFRM_MSG_DELPOLICY: case XFRM_MSG_NEWPOLICY: case XFRM_MSG_UPDPOLICY: + if (!xp) + break; return key_notify_policy(xp, dir, c); case XFRM_MSG_FLUSHPOLICY: if (c->data.type != XFRM_POLICY_TYPE_MAIN)
In pfkey_send_policy_notify(), there is an if statement on line 3081 to check whether xp is NULL: if (xp && xp->type != XFRM_POLICY_TYPE_MAIN) When xp is NULL, it is used by key_notify_policy() on line 3090: key_notify_policy(xp, ...) pfkey_xfrm_policy2msg_prep(xp) -- line 2211 pfkey_xfrm_policy2msg_size(xp) -- line 2046 for (i=0; i<xp->xfrm_nr; i++) -- line 2026 t = xp->xfrm_vec + i; -- line 2027 key_notify_policy(xp, ...) xp_net(xp) -- line 2231 return read_pnet(&xp->xp_net); -- line 534 Thus, possible null-pointer dereferences may occur. To fix these bugs, xp is checked before calling key_notify_policy(). These bugs are found by a static analysis tool STCheck written by us. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> --- net/key/af_key.c | 2 ++ 1 file changed, 2 insertions(+)