| Message ID | 1442858581-15869-2-git-send-email-ebiederm@xmission.com |
|---|---|
| State | Awaiting Upstream, archived |
| Delegated to: | David Miller |
| Headers | show |
On Mon, Sep 21, 2015 at 01:01:39PM -0500, Eric W. Biederman wrote: > Instead store ipvs in extra2 so that proc_do_defense_mode can easily > find the ipvs that it's value is associated with. > > Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> I am wondering if this fix should be included in v4.3 and stable. Can the problem occur in practice? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Simon Horman <horms@verge.net.au> writes: > On Mon, Sep 21, 2015 at 01:01:39PM -0500, Eric W. Biederman wrote: >> Instead store ipvs in extra2 so that proc_do_defense_mode can easily >> find the ipvs that it's value is associated with. >> >> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > > I am wondering if this fix should be included in v4.3 and stable. > Can the problem occur in practice? I believe a lookup in one network namespace followed by write in another network namespace would do it. So I think it would take so pretty deliberate and more or less peculiar actions to make it happen. I don't know how important the update_defense_level call is or how bad it is if it does not run in a network namespace . Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 22, 2015 at 08:53:30PM -0500, Eric W. Biederman wrote: > Simon Horman <horms@verge.net.au> writes: > > > On Mon, Sep 21, 2015 at 01:01:39PM -0500, Eric W. Biederman wrote: > >> Instead store ipvs in extra2 so that proc_do_defense_mode can easily > >> find the ipvs that it's value is associated with. > >> > >> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > > > > I am wondering if this fix should be included in v4.3 and stable. > > Can the problem occur in practice? > > I believe a lookup in one network namespace followed by write in another > network namespace would do it. So I think it would take so pretty > deliberate and more or less peculiar actions to make it happen. > > I don't know how important the update_defense_level call is or how bad > it is if it does not run in a network namespace . Thanks, my feeling is that this problem can be fixed via next. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c index 7338827ee5e9..6162ae56e47a 100644 --- a/net/netfilter/ipvs/ip_vs_ctl.c +++ b/net/netfilter/ipvs/ip_vs_ctl.c @@ -1615,7 +1615,7 @@ static int proc_do_defense_mode(struct ctl_table *table, int write, void __user *buffer, size_t *lenp, loff_t *ppos) { - struct net *net = current->nsproxy->net_ns; + struct netns_ipvs *ipvs = table->extra2; int *valp = table->data; int val = *valp; int rc; @@ -1626,7 +1626,7 @@ proc_do_defense_mode(struct ctl_table *table, int write, /* Restore the correct value */ *valp = val; } else { - update_defense_level(net_ipvs(net)); + update_defense_level(ipvs); } } return rc; @@ -3866,6 +3866,10 @@ static int __net_init ip_vs_control_net_init_sysctl(struct net *net) } else tbl = vs_vars; /* Initialize sysctl defaults */ + for (idx = 0; idx < ARRAY_SIZE(vs_vars); idx++) { + if (tbl[idx].proc_handler == proc_do_defense_mode) + tbl[idx].extra2 = ipvs; + } idx = 0; ipvs->sysctl_amemthresh = 1024; tbl[idx++].data = &ipvs->sysctl_amemthresh;
Instead store ipvs in extra2 so that proc_do_defense_mode can easily find the ipvs that it's value is associated with. Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> --- net/netfilter/ipvs/ip_vs_ctl.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)