Hi,
Running kmemcheck on -tip gives me the following warning:
kmemcheck: Caught 32-bit read from uninitialized memory (c72daa2e)
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiuuuuiiiiuuuuuuuuuu
^
Pid: 1345, comm: dhclient3 Tainted: G W
(2.6.26-rc8-tip-00186-ga644034 #60)
EIP: 0060:[<c028dd63>] EFLAGS: 00000206 CPU: 0
EIP is at __copy_user_intel+0x43/0xb0
EAX: 00000000 EBX: 0000024e ECX: 000000ce EDX: 00000000
ESI: c72da992 EDI: bff8e2f8 EBP: c68abd90 ESP: c0823f88
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: c68a0328 CR3: 06899000 CR4: 00000690
DR0: c0b98b7c DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00004000 DR7: 00000000
[<c028de27>] __copy_to_user_ll+0x57/0x60
[<c028e3f8>] copy_to_user+0x48/0x60
[<c04ade71>] memcpy_toiovec+0x41/0x60
[<c04ae461>] skb_copy_datagram_iovec+0x131/0x1e0
[<c05325c7>] packet_recvmsg+0xa7/0x1b0
[<c04a5aa3>] sock_aio_read+0xf3/0x100
[<c01a7c7d>] do_sync_read+0xcd/0x110
[<c01a8556>] vfs_read+0x126/0x130
[<c01a89ed>] sys_read+0x3d/0x70
[<c0104017>] sysenter_past_esp+0x78/0xc5
[<ffffffff>] 0xffffffff
..which is a bit worrying, because it means that we are copying
uninitialized data into userspace, i.e. this could be a data leak.
Most likely it's not very critical, but it would be nice to fix
anyway.
Relevant source lines are:
$ addr2line -e vmlinux -i c04ade71 # memcpy_toiovec
net/core/iovec.c:87
$ addr2line -e vmlinux -i c04ae461 # skb_copy_datagram_iovec
net/core/datagram.c:277
$ addr2line -e vmlinux -i c05325c7 # packet_recvmsg
net/packet/af_packet.c:1093
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
On Tue, Jul 01, 2008 at 11:16:15AM +0200, Vegard Nossum ([email protected]) wrote:
> Hi,
>
> Running kmemcheck on -tip gives me the following warning:
>
> kmemcheck: Caught 32-bit read from uninitialized memory (c72daa2e)
> iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiuuuuiiiiuuuuuuuuuu
> ^
...
> ..which is a bit worrying, because it means that we are copying
> uninitialized data into userspace, i.e. this could be a data leak.
> Most likely it's not very critical, but it would be nice to fix
> anyway.
>
> Relevant source lines are:
>
> $ addr2line -e vmlinux -i c04ade71 # memcpy_toiovec
> net/core/iovec.c:87
>
> $ addr2line -e vmlinux -i c04ae461 # skb_copy_datagram_iovec
> net/core/datagram.c:277
>
> $ addr2line -e vmlinux -i c05325c7 # packet_recvmsg
> net/packet/af_packet.c:1093
This gives:
copied = skb->len;
if (copied > len)
{
copied=len;
msg->msg_flags|=MSG_TRUNC;
}
err = skb_copy_datagram_iovec(skb, 0, msg->msg_iov, copied);
So everything looks ok, but driver could setup skb->len and/or
skb->data_len to be slightly more than it placed data. Does
above 'uuuu' bytes are at the end of the skb->data?
--
Evgeniy Polyakov
On Tue, Jul 1, 2008 at 12:25 PM, Evgeniy Polyakov <[email protected]> wrote:
>> $ addr2line -e vmlinux -i c05325c7 # packet_recvmsg
>> net/packet/af_packet.c:1093
>
> This gives:
> copied = skb->len;
> if (copied > len)
> {
> copied=len;
> msg->msg_flags|=MSG_TRUNC;
> }
>
> err = skb_copy_datagram_iovec(skb, 0, msg->msg_iov, copied);
>
> So everything looks ok, but driver could setup skb->len and/or
> skb->data_len to be slightly more than it placed data. Does
> above 'uuuu' bytes are at the end of the skb->data?
In fact I didn't give you the first such message. The first one looks like this:
kmemcheck: Caught 32-bit read from uninitialized memory (c72da052)
uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu
^
(with a similar stacktrace).
The u means uninitialized. So it seems not to be just the end. But I
am not sure where the end of the buffer is anyway.
But there is one thing I forgot: Is this memory initialized by DMA? If
so, the warning is bogus and I will go hide in shame.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
On Tue, Jul 01, 2008 at 12:52:53PM +0200, Vegard Nossum ([email protected]) wrote:
> The u means uninitialized. So it seems not to be just the end. But I
> am not sure where the end of the buffer is anyway.
>
> But there is one thing I forgot: Is this memory initialized by DMA? If
> so, the warning is bogus and I will go hide in shame.
It depends on driver, but sufficiently new hardware (or better say any
non-crappy hardware) will do dma transafer just into skb->data.
To catch it you can put kmemcheck hooks into pci_map* and friend
functions.
--
Evgeniy Polyakov
"Vegard Nossum" <[email protected]> writes:
> But there is one thing I forgot: Is this memory initialized by DMA? If
> so, the warning is bogus and I will go hide in shame.
Yes it is.
[btw that was something I noted during the initial review and was then
ridiculed for]
-Andi
Hi Andi,
"Vegard Nossum" <[email protected]> writes:
>> But there is one thing I forgot: Is this memory initialized by DMA? If
>> so, the warning is bogus and I will go hide in shame.
On Tue, Jul 1, 2008 at 2:47 PM, Andi Kleen <[email protected]> wrote:
> Yes it is.
>
> [btw that was something I noted during the initial review and was then
> ridiculed for]
Yes, you pointed that out but we sure as hell didn't ridicule you for
it. I even explicitly said that we're probably missing kmemcheck
annotations from other similar places as well (not just networking).
On Tue, Jul 1, 2008 at 1:47 PM, Andi Kleen <[email protected]> wrote:
> "Vegard Nossum" <[email protected]> writes:
>
>> But there is one thing I forgot: Is this memory initialized by DMA? If
>> so, the warning is bogus and I will go hide in shame.
>
> Yes it is.
>
> [btw that was something I noted during the initial review and was then
> ridiculed for]
I just went back and reviewed the original thread. (I assume you're
talking about the kmemcheck v3 thread,
http://lkml.org/lkml/2008/2/7/500.)
I'm sorry about having forgotten this particular comment you made.
Please take into account that before December last year, I didn't even
know what an skbuff was. And I didn't know how DMA worked. There can
be a lot of things that slip past when I don't have the basic mental
hooks on which to hang them. (Though, I must say, those discussions
have taught me a lot.) There was also the fact that Ingo for a long
time carried patches to silence these warnings, but which were dropped
before the 2.6.26 merge window because they should go through the
right maintainers instead of the x86 tree. I forgot about it, so I've
made a mistake this time.
But I don't see that you were ever ridiculed. In fact, I am only
grateful for all the comments you've made, and the help you've been.
Vegard
PS: The error I just reported was different from the ones we've had
before, which is why I didn't recognize it immediately.
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036