* Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y
@ 2017-11-30 18:37 Guenter Roeck
2017-12-01 15:09 ` Greg Kroah-Hartman
2017-12-01 19:48 ` Michal Kubecek
0 siblings, 2 replies; 6+ messages in thread
From: Guenter Roeck @ 2017-11-30 18:37 UTC (permalink / raw)
To: netdev; +Cc: stable, Greg Kroah-Hartman
Hi,
The fix for CVE-2017-16939 has been applied to v4.9.y, but not to v4.4.y
and older kernels. However, I confirmed that running the published POC
(see https://blogs.securiteam.com/index.php/archives/3535) does crash a 4.4
kernel.
I confirmed that the following two patches fix the problem in v4.4.y.
Please consider applying them to v4.4.y (and possibly v3.18.y).
fc9e50f5a5a4e ("netlink: add a start callback for starting a netlink dump")
1137b5e2529a8 ("ipsec: Fix aborted xfrm policy dump crash")
My apologies for the noise if this is already under consideration.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y
2017-11-30 18:37 Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y Guenter Roeck
@ 2017-12-01 15:09 ` Greg Kroah-Hartman
2017-12-01 19:48 ` Michal Kubecek
1 sibling, 0 replies; 6+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-01 15:09 UTC (permalink / raw)
To: Guenter Roeck; +Cc: netdev, stable
On Thu, Nov 30, 2017 at 10:37:40AM -0800, Guenter Roeck wrote:
> Hi,
>
> The fix for CVE-2017-16939 has been applied to v4.9.y, but not to v4.4.y
> and older kernels. However, I confirmed that running the published POC
> (see https://blogs.securiteam.com/index.php/archives/3535) does crash a 4.4
> kernel.
>
> I confirmed that the following two patches fix the problem in v4.4.y.
> Please consider applying them to v4.4.y (and possibly v3.18.y).
>
> fc9e50f5a5a4e ("netlink: add a start callback for starting a netlink dump")
> 1137b5e2529a8 ("ipsec: Fix aborted xfrm policy dump crash")
>
> My apologies for the noise if this is already under consideration.
Ah, thanks for this, I had tried this a few times, and asked around, but
missed that just adding the first patch here would solve the issue.
Both are now queued up, thanks for bringing this up again.
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y
2017-11-30 18:37 Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y Guenter Roeck
2017-12-01 15:09 ` Greg Kroah-Hartman
@ 2017-12-01 19:48 ` Michal Kubecek
2017-12-03 0:20 ` Guenter Roeck
1 sibling, 1 reply; 6+ messages in thread
From: Michal Kubecek @ 2017-12-01 19:48 UTC (permalink / raw)
To: Guenter Roeck; +Cc: netdev, stable, Greg Kroah-Hartman
On Thu, Nov 30, 2017 at 10:37:40AM -0800, Guenter Roeck wrote:
> Hi,
>
> The fix for CVE-2017-16939 has been applied to v4.9.y, but not to v4.4.y
> and older kernels. However, I confirmed that running the published POC
> (see https://blogs.securiteam.com/index.php/archives/3535) does crash a 4.4
> kernel.
>
> I confirmed that the following two patches fix the problem in v4.4.y.
> Please consider applying them to v4.4.y (and possibly v3.18.y).
>
> fc9e50f5a5a4e ("netlink: add a start callback for starting a netlink dump")
> 1137b5e2529a8 ("ipsec: Fix aborted xfrm policy dump crash")
>
> My apologies for the noise if this is already under consideration.
It's a bit too big hammer. As Nicolai Stange noticed when we were
handling this for SLE12 (where fc9e50f5a5a4e would break kABI), it's
much simpler to use the flag we already have in cb->args[0] to let
xfrm_dump_policy_done() call xfrm_policy_walk_done() only if the walk
structure has been initialized. Thus all you need is the patch below.
Michal Kubecek
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 7a5a64e70b4d..c01c7a7eb4d3 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1655,7 +1655,9 @@ static int xfrm_dump_policy_done(struct netlink_callback *cb)
struct xfrm_policy_walk *walk = (struct xfrm_policy_walk *) &cb->args[1];
struct net *net = sock_net(cb->skb->sk);
- xfrm_policy_walk_done(walk, net);
+ /* cb->args[0] is set when walk is initialized */
+ if (cb->args[0])
+ xfrm_policy_walk_done(walk, net);
return 0;
}
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y
2017-12-01 19:48 ` Michal Kubecek
@ 2017-12-03 0:20 ` Guenter Roeck
2017-12-03 0:44 ` Michal Kubecek
2017-12-04 12:05 ` Greg Kroah-Hartman
0 siblings, 2 replies; 6+ messages in thread
From: Guenter Roeck @ 2017-12-03 0:20 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, stable, Greg Kroah-Hartman
On 12/01/2017 11:48 AM, Michal Kubecek wrote:
> On Thu, Nov 30, 2017 at 10:37:40AM -0800, Guenter Roeck wrote:
>> Hi,
>>
>> The fix for CVE-2017-16939 has been applied to v4.9.y, but not to v4.4.y
>> and older kernels. However, I confirmed that running the published POC
>> (see https://blogs.securiteam.com/index.php/archives/3535) does crash a 4.4
>> kernel.
>>
>> I confirmed that the following two patches fix the problem in v4.4.y.
>> Please consider applying them to v4.4.y (and possibly v3.18.y).
>>
>> fc9e50f5a5a4e ("netlink: add a start callback for starting a netlink dump")
>> 1137b5e2529a8 ("ipsec: Fix aborted xfrm policy dump crash")
>>
>> My apologies for the noise if this is already under consideration.
>
> It's a bit too big hammer. As Nicolai Stange noticed when we were
The hammer is just as big as the upstream hammer. Personally I prefer the
upstream patch; I don't see a reason to deviate from upstream just because
the upstream solution is more complex than necessary.
> handling this for SLE12 (where fc9e50f5a5a4e would break kABI), it's
I didn't know that this is even a concern for stable releases. Is there
some guideline that kABI changes should be avoided in stable releases ?
Thanks,
Guenter
> much simpler to use the flag we already have in cb->args[0] to let
> xfrm_dump_policy_done() call xfrm_policy_walk_done() only if the walk
> structure has been initialized. Thus all you need is the patch below.
>
> Michal Kubecek
>
> diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> index 7a5a64e70b4d..c01c7a7eb4d3 100644
> --- a/net/xfrm/xfrm_user.c
> +++ b/net/xfrm/xfrm_user.c
> @@ -1655,7 +1655,9 @@ static int xfrm_dump_policy_done(struct netlink_callback *cb)
> struct xfrm_policy_walk *walk = (struct xfrm_policy_walk *) &cb->args[1];
> struct net *net = sock_net(cb->skb->sk);
>
> - xfrm_policy_walk_done(walk, net);
> + /* cb->args[0] is set when walk is initialized */
> + if (cb->args[0])
> + xfrm_policy_walk_done(walk, net);
> return 0;
> }
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y
2017-12-03 0:20 ` Guenter Roeck
@ 2017-12-03 0:44 ` Michal Kubecek
2017-12-04 12:05 ` Greg Kroah-Hartman
1 sibling, 0 replies; 6+ messages in thread
From: Michal Kubecek @ 2017-12-03 0:44 UTC (permalink / raw)
To: Guenter Roeck; +Cc: netdev, stable, Greg Kroah-Hartman
On Sat, Dec 02, 2017 at 04:20:40PM -0800, Guenter Roeck wrote:
> On 12/01/2017 11:48 AM, Michal Kubecek wrote:
> > On Thu, Nov 30, 2017 at 10:37:40AM -0800, Guenter Roeck wrote:
> > > Hi,
> > >
> > > The fix for CVE-2017-16939 has been applied to v4.9.y, but not to v4.4.y
> > > and older kernels. However, I confirmed that running the published POC
> > > (see https://blogs.securiteam.com/index.php/archives/3535) does crash a 4.4
> > > kernel.
> > >
> > > I confirmed that the following two patches fix the problem in v4.4.y.
> > > Please consider applying them to v4.4.y (and possibly v3.18.y).
> > >
> > > fc9e50f5a5a4e ("netlink: add a start callback for starting a netlink dump")
> > > 1137b5e2529a8 ("ipsec: Fix aborted xfrm policy dump crash")
> > >
> > > My apologies for the noise if this is already under consideration.
> >
> > It's a bit too big hammer. As Nicolai Stange noticed when we were
>
> The hammer is just as big as the upstream hammer. Personally I prefer the
> upstream patch; I don't see a reason to deviate from upstream just because
> the upstream solution is more complex than necessary.
Comparing that little patch with the combination of the two commits,
I would say we have a very different idea what "as big as" means. :-)
> > handling this for SLE12 (where fc9e50f5a5a4e would break kABI), it's
>
> I didn't know that this is even a concern for stable releases. Is there
> some guideline that kABI changes should be avoided in stable releases ?
Not to my knowledge, stable updates break kABI quite often. I just
mentioned it to explain why we had stronger motivation to find another
solution.
Michal Kubecek
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y
2017-12-03 0:20 ` Guenter Roeck
2017-12-03 0:44 ` Michal Kubecek
@ 2017-12-04 12:05 ` Greg Kroah-Hartman
1 sibling, 0 replies; 6+ messages in thread
From: Greg Kroah-Hartman @ 2017-12-04 12:05 UTC (permalink / raw)
To: Guenter Roeck; +Cc: Michal Kubecek, netdev, stable
On Sat, Dec 02, 2017 at 04:20:40PM -0800, Guenter Roeck wrote:
> On 12/01/2017 11:48 AM, Michal Kubecek wrote:
> > On Thu, Nov 30, 2017 at 10:37:40AM -0800, Guenter Roeck wrote:
> > > Hi,
> > >
> > > The fix for CVE-2017-16939 has been applied to v4.9.y, but not to v4.4.y
> > > and older kernels. However, I confirmed that running the published POC
> > > (see https://blogs.securiteam.com/index.php/archives/3535) does crash a 4.4
> > > kernel.
> > >
> > > I confirmed that the following two patches fix the problem in v4.4.y.
> > > Please consider applying them to v4.4.y (and possibly v3.18.y).
> > >
> > > fc9e50f5a5a4e ("netlink: add a start callback for starting a netlink dump")
> > > 1137b5e2529a8 ("ipsec: Fix aborted xfrm policy dump crash")
> > >
> > > My apologies for the noise if this is already under consideration.
> >
> > It's a bit too big hammer. As Nicolai Stange noticed when we were
>
> The hammer is just as big as the upstream hammer. Personally I prefer the
> upstream patch; I don't see a reason to deviate from upstream just because
> the upstream solution is more complex than necessary.
>
> > handling this for SLE12 (where fc9e50f5a5a4e would break kABI), it's
>
> I didn't know that this is even a concern for stable releases. Is there
> some guideline that kABI changes should be avoided in stable releases ?
Nope, for now I don't care about kABI changes in stable releases. I'd
almost always prefer to take the upstream patches exactly as-is.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-12-04 12:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-30 18:37 Fixing CVE-2017-16939 in v4.4.y and possibly v3.18.y Guenter Roeck
2017-12-01 15:09 ` Greg Kroah-Hartman
2017-12-01 19:48 ` Michal Kubecek
2017-12-03 0:20 ` Guenter Roeck
2017-12-03 0:44 ` Michal Kubecek
2017-12-04 12:05 ` Greg Kroah-Hartman
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).