linux-kernel - Re: Fwd: timerfd read only gets single byte?

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <469CA887.1080801@haxent.com.br>
Date:	Tue, 17 Jul 2007 08:31:19 -0300
From:	Davi Arnaut <davi@...ent.com.br>
To:	Michael Kerrisk <mtk-manpages@....net>
Cc:	Davide Libenzi <davidel@...ilserver.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Fwd: timerfd read only gets single byte?

Michael Kerrisk wrote:
 >
> Hi Davide,
> 
> While writing a test program to incorporate into the timerfd.2 man page, I
> think I've found a bug.  It looks like only the least significant byte of
> ticks is being returned from read(2), even though I am providing a 4 byte
> buffer.
> 
> The test program takes 3 command line arguments:
> 
> 1) seconds for the initial expiration
> 2) seconds for the timer interval
> 3) number of timer expirations to catch before terminating
> 
> I tried running this program and suspending it for a few minutes, to see if
> I could get a large overrun value.  When I do this on 2.6.22-rc4 (the built
> kernel I have to hand), I see the following:
> 
> ============
> $ ./timerfd_demo 1 1 500
> 0.000: timer started
> 1.005: read: 1; total=1
> 2.005: read: 1; total=2
> 3.005: read: 1; total=3
> 4.005: read: 1; total=4
> 5.006: read: 1; total=5
> ^Z
> [1]+  Stopped                 ./timerfd_demo 1 1 500
> $ date
> Tue Jul 17 09:18:11 CEST 2007
> $ date
> Tue Jul 17 09:23:40 CEST 2007
> $ fg
> ./timerfd_demo 1 1 500
> 339.769: read: 78; total=83
> 340.004: read: 1; total=84
> 341.004: read: 1; total=85
> ^C
> ==============
> 
> The after bringing the program back into the foreground, I would have
> expected to get an overrun count of 334 or thereabouts, but it looks as
> though I'm only getting the least significant byte from read(2).
> 
> Cheers,
> 
> Michael
> 
> [...]

put_user copies sizeof(*ptr) bytes to user space.

Signed-off-by: Davi Arnaut <davi@...ent.com.br


diff --git a/fs/timerfd.c b/fs/timerfd.c
index af9eca5..e9f73f5 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -140,7 +140,8 @@ static ssize_t timerfd_read(struct file *file, char
__user *buf, size_t count,
 	}
 	spin_unlock_irq(&ctx->wqh.lock);
 	if (ticks)
-		res = put_user(ticks, buf) ? -EFAULT: sizeof(ticks);
+		res = put_user(ticks, ((u32 __user *)buf)) ? -EFAULT :
+							      sizeof(ticks);
 	return res;
 }

-
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/