First off, sorry to bring such an old email back but I can seem to get
a bad feeling when looking back over it.
On Tue, Apr 29, 2008 at 6:13 AM, Denis V. Lunev <[email protected]> wrote:
> The check for PDE->data != NULL becomes useless after the replacement
> of proc_net_fops_create with proc_create_data.
>
> Signed-off-by: Denis V. Lunev <[email protected]>
> Cc: Alexey Dobriyan <[email protected]>
> Cc: Eric W. Biederman <[email protected]>
> Cc: David S. Miller <[email protected]>
> ---
> net/ipv4/tcp_ipv4.c | 10 +++-------
> net/ipv4/udp.c | 7 +++----
> 2 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 7766151..4d97b28 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -2214,9 +2214,6 @@ static int tcp_seq_open(struct inode *inode, struct file *file)
> struct tcp_iter_state *s;
> int err;
>
> - if (unlikely(afinfo == NULL))
> - return -EINVAL;
I think that this check needs to stay in some form, reason below.
> -
> err = seq_open_net(inode, file, &afinfo->seq_ops,
> sizeof(struct tcp_iter_state));
> if (err < 0)
> @@ -2241,10 +2238,9 @@ int tcp_proc_register(struct net *net, struct tcp_seq_afinfo *afinfo)
> afinfo->seq_ops.next = tcp_seq_next;
> afinfo->seq_ops.stop = tcp_seq_stop;
>
> - p = proc_net_fops_create(net, afinfo->name, S_IRUGO, &afinfo->seq_fops);
> - if (p)
> - p->data = afinfo;
> - else
> + p = proc_create_data(afinfo->name, S_IRUGO, net->proc_net,
When you try to pass in afinfo->name (and also the seq_fops) you are
assuming that afinfo is not null meaning in the unlikely(as shown
above) even that it is null you get a very bad null pointer problem.
If I am just way off do let me know because this just seams to me like
a bad idea. This is also still present in 2.6.26-rc9.
-Stoyan G
> + &afinfo->seq_fops, afinfo);
> + if (!p)
> rc = -ENOMEM;
> return rc;
> }
> diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
> index b053ac7..c19c491 100644
> --- a/net/ipv4/udp.c
> +++ b/net/ipv4/udp.c
> @@ -1605,10 +1605,9 @@ int udp_proc_register(struct net *net, struct udp_seq_afinfo *afinfo)
> afinfo->seq_ops.next = udp_seq_next;
> afinfo->seq_ops.stop = udp_seq_stop;
>
> - p = proc_net_fops_create(net, afinfo->name, S_IRUGO, &afinfo->seq_fops);
> - if (p)
> - p->data = afinfo;
> - else
> + p = proc_create_data(afinfo->name, S_IRUGO, net->proc_net,
> + &afinfo->seq_fops, afinfo);
> + if (!p)
> rc = -ENOMEM;
> return rc;
> }
> --
> 1.5.3.rc5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
"Stoyan Gaydarov" <[email protected]> writes:
> First off, sorry to bring such an old email back but I can seem to get
> a bad feeling when looking back over it.
>
> On Tue, Apr 29, 2008 at 6:13 AM, Denis V. Lunev <[email protected]> wrote:
>> The check for PDE->data != NULL becomes useless after the replacement
>> of proc_net_fops_create with proc_create_data.
>>
>> Signed-off-by: Denis V. Lunev <[email protected]>
>> Cc: Alexey Dobriyan <[email protected]>
>> Cc: Eric W. Biederman <[email protected]>
>> Cc: David S. Miller <[email protected]>
>> ---
>> net/ipv4/tcp_ipv4.c | 10 +++-------
>> net/ipv4/udp.c | 7 +++----
>> 2 files changed, 6 insertions(+), 11 deletions(-)
>>
>> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
>> index 7766151..4d97b28 100644
>> --- a/net/ipv4/tcp_ipv4.c
>> +++ b/net/ipv4/tcp_ipv4.c
>> @@ -2214,9 +2214,6 @@ static int tcp_seq_open(struct inode *inode, struct file
> *file)
>> struct tcp_iter_state *s;
>> int err;
>>
>> - if (unlikely(afinfo == NULL))
>> - return -EINVAL;
> I think that this check needs to stay in some form, reason below.
>> -
>> err = seq_open_net(inode, file, &afinfo->seq_ops,
>> sizeof(struct tcp_iter_state));
>> if (err < 0)
>> @@ -2241,10 +2238,9 @@ int tcp_proc_register(struct net *net, struct
> tcp_seq_afinfo *afinfo)
>> afinfo->seq_ops.next = tcp_seq_next;
>> afinfo->seq_ops.stop = tcp_seq_stop;
>>
>> - p = proc_net_fops_create(net, afinfo->name, S_IRUGO, &afinfo->seq_fops);
>> - if (p)
>> - p->data = afinfo;
>> - else
>> + p = proc_create_data(afinfo->name, S_IRUGO, net->proc_net,
>
> When you try to pass in afinfo->name (and also the seq_fops) you are
> assuming that afinfo is not null meaning in the unlikely(as shown
> above) even that it is null you get a very bad null pointer problem.
> If I am just way off do let me know because this just seams to me like
> a bad idea. This is also still present in 2.6.26-rc9.
It appears you are getting things confused. The original window is that tcp_seq_open
(which is what get called when you open the proc file) had a small race that p->data
could be read before it was set.
With proc_create_data that race was closed.
You are saying that it is a problem for tcp_seq_open to be passed a NULL afinfo.
It is. That has nothing to do with the original race (as that is a very
different part of the code). Feel free to audit all of the callers if
you like. That problem however is not subtle or racy.
So I see nothing wrong with this patch unless you can find a problem with
proc_create_data.
Eric
On Fri, 2008-07-11 at 22:12 -0500, Stoyan Gaydarov wrote:
> First off, sorry to bring such an old email back but I can seem to get
> a bad feeling when looking back over it.
>
> On Tue, Apr 29, 2008 at 6:13 AM, Denis V. Lunev <[email protected]> wrote:
> > The check for PDE->data != NULL becomes useless after the replacement
> > of proc_net_fops_create with proc_create_data.
> >
> > Signed-off-by: Denis V. Lunev <[email protected]>
> > Cc: Alexey Dobriyan <[email protected]>
> > Cc: Eric W. Biederman <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > ---
> > net/ipv4/tcp_ipv4.c | 10 +++-------
> > net/ipv4/udp.c | 7 +++----
> > 2 files changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> > index 7766151..4d97b28 100644
> > --- a/net/ipv4/tcp_ipv4.c
> > +++ b/net/ipv4/tcp_ipv4.c
> > @@ -2214,9 +2214,6 @@ static int tcp_seq_open(struct inode *inode, struct file *file)
> > struct tcp_iter_state *s;
> > int err;
> >
> > - if (unlikely(afinfo == NULL))
> > - return -EINVAL;
> I think that this check needs to stay in some form, reason below.
> > -
> > err = seq_open_net(inode, file, &afinfo->seq_ops,
> > sizeof(struct tcp_iter_state));
> > if (err < 0)
> > @@ -2241,10 +2238,9 @@ int tcp_proc_register(struct net *net, struct tcp_seq_afinfo *afinfo)
> > afinfo->seq_ops.next = tcp_seq_next;
> > afinfo->seq_ops.stop = tcp_seq_stop;
> >
> > - p = proc_net_fops_create(net, afinfo->name, S_IRUGO, &afinfo->seq_fops);
> > - if (p)
> > - p->data = afinfo;
> > - else
> > + p = proc_create_data(afinfo->name, S_IRUGO, net->proc_net,
>
> When you try to pass in afinfo->name (and also the seq_fops) you are
> assuming that afinfo is not null meaning in the unlikely(as shown
> above) even that it is null you get a very bad null pointer problem.
> If I am just way off do let me know because this just seams to me like
> a bad idea. This is also still present in 2.6.26-rc9.
The reason to remove the check is simple - afinfo comes in the form of
the static pointer during init time. It is impossible to face NULL
pointer the problem in the reality. It can come as the programmer
mistake, but the OOPS will be immediate and straightforward. Namely, the
kernel will not boot/work at all.
Regards,
Den