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 <[email protected]>
---
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;
return key_notify_policy(xp, dir, c);
case XFRM_MSG_FLUSHPOLICY:
if (c->data.type != XFRM_POLICY_TYPE_MAIN)
--
2.17.0
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 <[email protected]>
> ---
> 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 <[email protected]>
> > ---
> > 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.