linux-kernel - RFC: Inconsistent short read behaviour in __do_proc_dointvec vs _proc_do

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Wed, 21 Dec 2011 10:10:47 -0800
From:	Earl Chew <echew@...acom.com>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RFC: Inconsistent short read behaviour in __do_proc_dointvec vs _proc_do_string

Should repeated short reads in __do_proc_dointvec behave consistently with _proc_do_string ?

Consider:

>     char c[1];
>     int n;
> 
>     while (1)
>     {
>         n = read(0, c, 1);
> 
>         if (n <= 0) break;
> 
>         write (1, c, 1);
>     }

Running this program on /proc/self/stat emits the expected output.

Running this program on /proc/sys/kernel/random/poolsize does not :-(

The issue is that __do_proc_dointvec does not accommodate non-zero file positions
when reading:

>         if (!tbl_data || !table->maxlen || !*lenp || (*ppos && !write)) {
>                *lenp = 0;
>                return 0;
>         }


OTOH _proc_do_string seems quite willing to accommodate it:

>         if (write) {
>            ...
>         } else {
>            len = strlen(data);
>            if (len > maxlen)
>                     len = maxlen;
>
>            if (*ppos > len) {
>                     *lenp = 0;
>                     return 0;
>            }


Should __do_proc_intvec behave more like _proc_do_string, or vice-versa ?


Earl


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/