linux-kernel - Re: [PATCH 2/2] proc: fix PAGE_SIZE limit of /proc/$PID/cmdline

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: <20150528113507.GK17625@uranus.sw.swsoft.com>
Date:	Thu, 28 May 2015 14:35:07 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Jarod Wilson <jarod@...hat.com>,
	Jan Stancek <jstancek@...hat.com>
Subject: Re: [PATCH 2/2] proc: fix PAGE_SIZE limit of /proc/$PID/cmdline

On Thu, May 28, 2015 at 02:14:41PM +0300, Alexey Dobriyan wrote:
> >>
> >> It is snapshot w.r.t getting both pairs not snapshot w.r.t atomicity or
> >> something (unsigned long access is atomic after all). Once down_write()
> >> is used in the other place, it even becomes obviously correct code!
> >
> > Not at all. It is correct if and only if you're operating under lock
> > taken, once you fetch the pair and left the lock it simply local copies
> > of values the descriptor had when lock was taken.
> 
> Yes, and?
> 
> You do not complain that signal statistics is collected
> under sighand lock but printed for /proc/*/status without, do you?

They are different, in signal statistics we fetch the _complete_
entries, ie full copies of data. In turn you fetch only pointers
to data. Don't you see the difference? IOW, prctl modifies members
under the lock testing both the pointers and the data they points
to are valid _under_ the lock, but you instead fetch the addresses
under the lock, leave lock and continue operating with addresses,
which is wrong imho.

(I don't see some serious problem here because in worst scenario
 (if someone set up bad pointers here) we simply get page fault
 or some related error for application, not the kernel itself,
 so I won't insist).
--
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/