* [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
@ 2019-07-29 3:43 Jia-Ju Bai
2019-07-29 8:03 ` Steffen Klassert
0 siblings, 1 reply; 3+ messages in thread
From: Jia-Ju Bai @ 2019-07-29 3:43 UTC (permalink / raw)
To: steffen.klassert, herbert, davem; +Cc: netdev, linux-kernel
In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm
is NULL.
Then, dst->xfrm is used on line 3840:
xfrm_state_mtu(dst->xfrm, mtu);
if (x->km.state != XFRM_STATE_VALID...)
aead = x->data;
Thus, possible null-pointer dereferences may occur.
These bugs are found by a static analysis tool STCheck written by us.
I do not know how to correctly fix these bugs, so I only report them.
Best wishes,
Jia-Ju Bai
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
2019-07-29 3:43 [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy() Jia-Ju Bai
@ 2019-07-29 8:03 ` Steffen Klassert
2019-07-29 8:06 ` Jia-Ju Bai
0 siblings, 1 reply; 3+ messages in thread
From: Steffen Klassert @ 2019-07-29 8:03 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: herbert, davem, netdev, linux-kernel
On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
> NULL.
We don't have a xfrm_policy() function, and as said already the
line numbers does not help much as long as you don't say which
tree/branch this is and which commit is the head commit.
> Then, dst->xfrm is used on line 3840:
> xfrm_state_mtu(dst->xfrm, mtu);
> if (x->km.state != XFRM_STATE_VALID...)
> aead = x->data;
>
> Thus, possible null-pointer dereferences may occur.
I guess you refer to xfrm_bundle_ok(). The dst pointer
is reoaded after the loop, so the dereferenced pointer
is not the one that had NULL at dst->xfrm.
>
> These bugs are found by a static analysis tool STCheck written by us.
>
> I do not know how to correctly fix these bugs, so I only report them.
I'd suggest you to manually review the reports of your
tool and to fix the tool accordingly.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
2019-07-29 8:03 ` Steffen Klassert
@ 2019-07-29 8:06 ` Jia-Ju Bai
0 siblings, 0 replies; 3+ messages in thread
From: Jia-Ju Bai @ 2019-07-29 8:06 UTC (permalink / raw)
To: Steffen Klassert; +Cc: herbert, davem, netdev, linux-kernel
On 2019/7/29 16:03, Steffen Klassert wrote:
> On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
>> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
>> NULL.
> We don't have a xfrm_policy() function, and as said already the
> line numbers does not help much as long as you don't say which
> tree/branch this is and which commit is the head commit.
>
>> Then, dst->xfrm is used on line 3840:
>> xfrm_state_mtu(dst->xfrm, mtu);
>> if (x->km.state != XFRM_STATE_VALID...)
>> aead = x->data;
>>
>> Thus, possible null-pointer dereferences may occur.
> I guess you refer to xfrm_bundle_ok(). The dst pointer
> is reoaded after the loop, so the dereferenced pointer
> is not the one that had NULL at dst->xfrm.
>
>> These bugs are found by a static analysis tool STCheck written by us.
>>
>> I do not know how to correctly fix these bugs, so I only report them.
> I'd suggest you to manually review the reports of your
> tool and to fix the tool accordingly.
Oh, sorry for my mistakes.
I have found that dst is updated:
dst = &xdst->u.dst;
I will fix my tool, thanks.
Best wishes,
Jia-Ju Bai
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-29 8:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-29 3:43 [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy() Jia-Ju Bai
2019-07-29 8:03 ` Steffen Klassert
2019-07-29 8:06 ` Jia-Ju Bai
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).