Control: severity -1 normal On Fri, 2016-09-09 at 15:37 -0400, Wolfgang Tichy wrote: > Package: src:linux > Version: 3.16.7-ckt25-2+deb8u3 > Severity: critical > Tags: security > Justification: causes serious data loss > > Dear Maintainer, > > when I open a particular word document (it contains images and I can send it > to you for testing) with libreoffice, all memory and all swap get used up > within about a minute. This happens slowly enough that it can be monitored > with "top" and "free". What I see with top is that soffice.bin (which is > libreoffice) does not use much memory (maybe 2%). Nevertheless more and more > memory gets used.
> "free -h" gives something like this: > > total used free shared buffers cached > Mem: 7.5G 7.4G 141M 5.9G 71M 6.4G > -/+ buffers/cache: 917M 6.6G > Swap: 8.0G 663M 7.4G > > Eventually the "used" column in the "Mem:" and "Swap:" and lines reach the > total and the system runs out of memory and becomes totally unresponsive > (even the mouse pointer freezes), no remote logins are possible at this > point, and all keypresses are ignored. The only way to regain control is by > holding down the power button for 10s. Alt-SysRq Alt-K would probably work. > However, the "used" column in the > "-/+ buffers/cache:" line stays near 1GB, so that it is clear that > buffers/caches take up almost all the space. > > You may wonder why I file this against the kernel and not libreoffice. Well, > I am sure libreoffice is doing something stupid, that could be fixed to > circumvent this problem. But the kernel should simply not allow any user > process to bring down the entire system. Also it seems the kernel is > allocating caches or buffers until it runs out of all memory and then > freezes. A large number for caches or buffers does not indicate a problem. That is absolutely normal. I think the problem is the 'shared' memory; that very likely corresponds to graphics buffers (shared between LibreOffice, the X server and the kernel graphics driver). [...] > On this one, Gnome3 crashes and dmesg has a lot of lines lines like: > [880754.926611] [TTM] Failed to find memory space for buffer > 0xffff880367e42800 eviction > [880754.926613] [TTM] No space for ffff880367e42800 (497 pages, 1988K, 1M) > [880754.926614] [TTM] placement[0]=0x00070002 (1) > [880754.926616] [TTM] has_type: 1 > [880754.926617] [TTM] use_type: 1 > [880754.926618] [TTM] flags: 0x0000000A > [880754.926619] [TTM] gpu_offset: 0x00000000 > [880754.926620] [TTM] size: 131072 > [880754.926621] [TTM] available_caching: 0x00070000 > [880754.926622] [TTM] default_caching: 0x00010000 [...] And that's an attempt to allocate such a graphics buffer. > This is actually good because after the gnome3 crash the system is still > usable. I should say that in all cases I am using the open source graphics > drivers that use kernel mode setting. So the latter crash leads me to think > that some interaction between the graphics drivers and the kernel leads to > the allocation of too many buffers/caches by the kernel until it runs out. > Probably this is all triggered by libreoffice (running on X) trying to > display some JPG images in a document. > > The reason why I consider this security relevant is that anybody with a user > account can use libreoffice to bring the system down. This sounds like CVE-2013-7445 which is unlikely to be fixed in jessie. > This will cause data loss since all other users cannot save any data in open > files. Losing data from memory doesn't count. But please do open bugs on applications that don't implement auto-save. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it.
signature.asc
Description: This is a digitally signed message part
