linux-kernel - Re: Problems with timerfd()

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

Message-ID: <46A46082.7030301@gmx.net>
Date:	Mon, 23 Jul 2007 10:02:10 +0200
From:	Michael Kerrisk <mtk-manpages@....net>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	lkml <linux-kernel@...r.kernel.org>,
	Linux Torvalds <torvalds@...ux-foundation.org>,
	Davide Libenzi <davidel@...ilserver.org>, drepper@...hat.com,
	stable@...nel.org
Subject: Re: Problems with timerfd()

Andrew Morton wrote:
> On Sun, 22 Jul 2007 23:38:26 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
>>> Davide has already submitted a patch to you to make read() from a timerfd
>>> file descriptor return an 8 byte integer, and I understand it to have been
>>> accepted into -mm.
>> argh.  Nobody told me it was an ABI change!  We'll need to consider merging
>> make-timerfd-return-a-u64-and-fix-the-__put_user.patch into 2.6.22.x as
>> well.
>>
> 
> So I'm trying to write a halfway respectable description of that patch and
> I'm stuck when it comes to describing what will happen if someone tries
> to run a future timerfd-enabled glibc on 2.2.22 base.   In what manner
> will it misbehave?  What are the consequences of this decision?
> 

The difference would be that read() will only return 4 bytes, while the
application will expect 8.  If the application is checking the size of
returned value, as it should, then it will be able to detect the problem
(it could even be sophisticated enough to know that if this is a 4-byte
return, then it is running on an old 2.6.22 kernel).  If the application is
not checking the return from read(), then its 8-byte buffer will not be
filled -- the contents of the last 4 bytes will be undefined, so the u64
value as a whole will be junk.

Cheers,

Michael

-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7

Want to help with man page maintenance?  Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.
-
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/