linux-kernel - Re: [PATCH] kmsg: properly handle concurrent non-blocking read() from /proc/kmsg

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

Message-Id: <4FF3EF3A0200007800087520@nat28.tlf.novell.com>
Date:	Wed, 04 Jul 2012 07:22:34 +0100
From:	"Jan Beulich" <jbeulich@...e.com>
To:	<gregkh@...uxfoundation.org>, <kay@...y.org>
Cc:	<yuanhan.liu@...ux.intel.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kmsg: properly handle concurrent non-blocking
 read() from /proc/kmsg

>>> Kay Sievers <kay@...y.org> 07/03/12 8:17 PM >>>
>From: Kay Sievers <kay@...y.org>
>Subject: kmsg: properly handle concurrent non-blocking read() from /proc/kmsg
>
>The /proc/kmsg read() interface is internally simply wired up to a sequence
>of syslog() syscalls, which might are racy between their checks and actions,
>regarding concurrency.
>
>In the (very uncommon) case of concurrent readers of /dev/kmsg, relying on
>usual O_NONBLOCK behavior, the recently introduced mutex might block an
>O_NONBLOCK reader in read(), when poll() returns for it, but another process
>has already read the data in the meantime. We've seen that while running
>artificial test setups and tools that "fight" about /proc/kmsg data.
>
>This restores the original /proc/kmsg behavior, where in case of concurrent
>read()s, poll() might wake up but the read() syscall will just return 0 to
>the caller, while another process has "stolen" the data.
>
>This is in the general case not the expected behavior, but it is the exact
>same one, that can easily be triggered with a 3.4 kernel, and some tools
>might just rely on it.
>
>The mutex is not needed, the original integrity issue which introduced it,
>is in the meantime covered by:
>"fill buffer with more than a single message for SYSLOG_ACTION_READ"
  >116e90b23f74d303e8d607c7a7d54f60f14ab9f2
>
>Cc: Yuanhan Liu <yuanhan.liu@...ux.intel.com>
>Cc: Jan Beulich <JBeulich@...e.com>
>Signed-off-by: Kay Sievers <kay@...y.org>

This being a revert of all but a single change of
4a77a5a06ec66ed05199b301e7c25f42f979afdc, which I had suggested to
be reverted anyway:

Acked-by: Jan Beulich <jbeulich@...e.com>


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