Bug 920632 (CVE-2014-8172) - VUL-1: CVE-2014-8172: kernel-source: soft lockup on aio
Summary: VUL-1: CVE-2014-8172: kernel-source: soft lockup on aio
Status: RESOLVED UPSTREAM
Alias: CVE-2014-8172
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P4 - Low : Normal
Target Milestone: ---
Assignee: E-mail List
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/114412/
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-04 14:27 UTC by Marcus Meissner
Modified: 2016-04-27 20:09 UTC (History)
3 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2015-03-04 14:27:14 UTC 
via kernel git and redhat bugzilla:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=eee5cc2702929fd41cce28058dc6d6717f723f87


commit eee5cc2702929fd41cce28058dc6d6717f723f87
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Fri Oct 4 11:06:42 2013 -0400

    get rid of s_files and files_lock
    
    The only thing we need it for is alt-sysrq-r (emergency remount r/o)
    and these days we can do just as well without going through the
    list of files.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>



... This probably needs to be reduced to be kabi transparent.
Comment 1 Marcus Meissner 2015-03-04 14:28:05 UTC 
Was fixed in 3.12, so SLES 12 should already have the fix. Older ones need it.
Comment 3 Michal Hocko 2015-03-04 16:43:19 UTC 
OK, so I have checked the usage of the files_lglock. There are only two places where the lock could lead to long stalls because we are iterating over potentially many items; fs_may_remount_ro and  mark_files_ro which happen when a filesystem is supposed to be remounted RO. This might happen during sysrq or remount commands which both have to be explicitly enabled or need root permissions unless I am missing something.

This makes me even more dubious about this report. a) having softlockup setup to panic is not appropriate for the production systems (CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE is 0 by default) and b) even if the panic is enabled it should be only root to trigger this.
Comment 4 Michal Hocko 2015-03-04 16:47:20 UTC 
btw. what does this have to do with AIO?
Comment 5 Jiri Kosina 2015-03-04 17:03:00 UTC 
Also, I am not able to find CVE-2014-8172 on NVD ... ?
Comment 7 Swamp Workflow Management 2015-03-04 23:00:34 UTC 
bugbot adjusting priority
Comment 16 Marcus Meissner 2015-04-10 12:09:03 UTC 
I think all is resolved.

No SLES versions affected.