linux-kernel - Re: [PATCH] printk: use mutex lock to stop syslog

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAPXgP11QdNqMzKEuAqfA8SYLLVTeDVHp1L29L71rVHO32t+B7Q@mail.gmail.com>
Date:	Sat, 16 Jun 2012 16:38:54 +0200
From:	Kay Sievers <kay@...y.org>
To:	Yuanhan Liu <yuanhan.liu@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, wfg@...ux.intel.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] printk: use mutex lock to stop syslog_seq from going wild

On Sat, Jun 16, 2012 at 3:21 PM, Yuanhan Liu
<yuanhan.liu@...ux.intel.com> wrote:
> Although syslog_seq and log_next_seq stuff are protected by logbuf_lock
> spin log, it's not enough. Say we have two processes A and B, and let
> syslog_seq = N, while log_next_seq = N + 1, and the two processes both
> come to syslog_print at almost the same time. And No matter which
> process get the spin lock first, it will increase syslog_seq by one,
> then release spin lock; thus later, another process increase syslog_seq
> by one again. In this case, syslog_seq is bigger than syslog_next_seq.
> And latter, it would make:
>   wait_event_interruptiable(log_wait, syslog != log_next_seq)
> don't wait any more even there is no new write comes. Thus it introduce
> a infinite loop reading.
>
> I can easily see this kind of issue by the following steps:
>  # cat /proc/kmsg # at meantime, I don't kill rsyslog
>                   # So they are the two processes.
>  # xinit          # I added drm.debug=6 in the kernel parameter line,
>                   # so that it will produce lots of message and let that
>                   # issue happen
>
> It's 100% reproducable on my side. And my disk will be filled up by
> /var/log/messages in a quite short time.
>
> So, introduce a mutex_lock to stop syslog_seq from going wild just like
> what devkmsg_read() does. It does fix this issue as expected.
>
> v2: use mutex_lock_interruptiable() instead (comments from Kay)
>
> Cc: Kay Sievers <kay@...y.org>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Signed-off-by: Yuanhan Liu <yuanhan.liu@...ux.intel.com>

Acked-By: Kay Sievers <kay@...y.org>

Thanks again for finding and fixing it.

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