- 11 Apr, 2018 40 commits
-
-
Chris Wilson authored
As using an unsafe module parameter is, by its very definition, an expected user action, emitting a warning is overkill. Nothing has yet gone wrong, and we add a taint flag for any future oops should something actually go wrong. So instead of having a user controllable pr_warn, downgrade it to a pr_notice for "a normal, but significant condition". We make use of unsafe kernel parameters in igt (https://cgit.freedesktop.org/drm/igt-gpu-tools/) (we have not yet succeeded in removing all such debugging options), which generates a warning and taints the kernel. The warning is unhelpful as we then need to filter it out again as we check that every test themselves do not provoke any kernel warnings. Link: http://lkml.kernel.org/r/20180226151919.9674-1-chris@chris-wilson.co.uk Fixes: 91f9d330 ("module: make it possible to have unsafe, tainting module params") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Jean Delvare <khali@linux-fr.org> Cc: Li Zhong <zhong@linux.vnet.ibm.com> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Randy Dunlap authored
Fix sizeof argument to be the same as the data variable name. Probably a copy/paste error. Mostly harmless since both variables are unsigned int. Fixes kernel bugzilla #197371: Possible access to unintended variable in "kernel/sysctl.c" line 1339 https://bugzilla.kernel.org/show_bug.cgi?id=197371 Link: http://lkml.kernel.org/r/e0d0531f-361e-ef5f-8499-32743ba907e1@infradead.orgSigned-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
Petru Mihancea <petrum@gmail.com> Signed-off-by:
-
Ioan Nicu authored
Once the dma request is passed to the DMA engine, the DMA subsystem would hold a pointer to this structure and could call the completion callback after do_dma_request() has timed out. The current code deals with this by putting timed out SYNC requests to a pending list and freeing them later, when the mport cdev device is released. This still does not guarantee that the DMA subsystem is really done with those transfers, so in theory dma_xfer_callback/dma_req_free could be called after mport_cdev_release_dma and could potentially access already freed memory. This patch simplifies the current handling by using a kref in the mport dma request structure, so that it gets freed only when nobody uses it anymore. This also simplifies the code a bit, as FAF transfers are now handled in the same way as SYNC and ASYNC transfers. There is no need anymore for the pending list and for the dma workqueue which was used in case of FAF transfers, so we remove them both. Link: http://lkml.kernel.org/r/20180405203342.GA16191@nokia.comSigned-off-by:
Ioan Nicu <ioan.nicu.ext@nokia.com> Acked-by:
Alexandre Bounine <alex.bou9@gmail.com> Cc: Barry Wood <barry.wood@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Logan Gunthorpe <logang@deltatee.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Frank Kunz <frank.kunz@nokia.com> Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
-
Vasyl Gomonovych authored
Fix typo in the words 'receiver', 'specified', 'during' Link: http://lkml.kernel.org/r/20180321211035.8904-1-gomonovych@gmail.comSigned-off-by:
Vasyl Gomonovych <gomonovych@gmail.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Alexandre Bounine <alexandre.bounine@idt.com> Signed-off-by:
-
Kees Cook authored
Since the stack rlimit is used in multiple places during exec and it can be changed via other threads (via setrlimit()) or processes (via prlimit()), the assumption that the value doesn't change cannot be made. This leads to races with mm layout selection and argument size calculations. This changes the exec path to use the rlimit stored in bprm instead of in current. Before starting the thread, the bprm stack rlimit is stored back to current. Link: http://lkml.kernel.org/r/1518638796-20819-4-git-send-email-keescook@chromium.org Fixes: 64701dee ("exec: Use sane stack rlimit under secureexec") Signed-off-by:
Kees Cook <keescook@chromium.org> Reported-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Reported-by:
Andy Lutomirski <luto@kernel.org> Reported-by:
Brad Spengler <spender@grsecurity.net> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Greg KH <greg@kroah.com> Cc: Hugh Dickins <hughd@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Laura Abbott <labbott@redhat.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Kees Cook authored
Provide a final callback into fs/exec.c before start_thread() takes over, to handle any last-minute changes, like the coming restoration of the stack limit. Link: http://lkml.kernel.org/r/1518638796-20819-3-git-send-email-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
Patch series "exec: Pin stack limit during exec". Attempts to solve problems with the stack limit changing during exec continue to be frustrated[1][2]. In addition to the specific issues around the Stack Clash family of flaws, Andy Lutomirski pointed out[3] other places during exec where the stack limit is used and is assumed to be unchanging. Given the many places it gets used and the fact that it can be manipulated/raced via setrlimit() and prlimit(), I think the only way to handle this is to move away from the "current" view of the stack limit and instead attach it to the bprm, and plumb this down into the functions that need to know the stack limits. This series implements the approach. [1] 04e35f44 ("exec: avoid RLIMIT_STACK races with prlimit()") [2] 779f4e1c ("Revert "exec: avoid RLIMIT_STACK races with prlimit()"") [3] to security@kernel.org, "Subject: existing rlimit races?" This patch (of 3): Since it is possible that the stack rlimit can change externally during exec (either via another thread calling setrlimit() or another process calling prlimit()), provide a way to pass the rlimit down into the per-architecture mm layout functions so that the rlimit can stay in the bprm structure instead of sitting in the signal structure until exec is finalized. Link: http://lkml.kernel.org/r/1518638796-20819-2-git-send-email-keescook@chromium.orgSigned-off-by:
-
Alexey Dobriyan authored
All it takes to open a file and read 1 byte from it. seq_file will be allocated along with any private allocations, and more importantly seq file buffer which is 1 page by default. Link: http://lkml.kernel.org/r/20180310085252.GB17121@avx2Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by:
-
Alexey Dobriyan authored
For fine-grained debugging and usercopy protection. Link: http://lkml.kernel.org/r/20180310085027.GA17121@avx2Signed-off-by:
-
Andrew Morton authored
One use of the reiserfs_warning() macro in journal_init_dev() is missing a parameter, causing the following warning: REISERFS warning (device loop0): journal_init_dev: Cannot open '%s': %i journal_init_dev: This also causes a WARN_ONCE() warning in the vsprintf code, and then a panic if panic_on_warn is set. Please remove unsupported %/ in format string WARNING: CPU: 1 PID: 4480 at lib/vsprintf.c:2138 format_decode+0x77f/0x830 lib/vsprintf.c:2138 Kernel panic - not syncing: panic_on_warn set ... Just add another string argument to the macro invocation. Addresses https://syzkaller.appspot.com/bug?id=0627d4551fdc39bf1ef5d82cd9eef587047f7718 Link: http://lkml.kernel.org/r/d678ebe1-6f54-8090-df4c-b9affad62293@infradead.orgSigned-off-by:
Jeff Mahoney <jeffm@suse.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jan Kara <jack@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Matthew Wilcox authored
This playing with signals to allow only fatal signals appears to predate the introduction of wait_event_killable(), and I'm fairly sure that wait_event_killable is what was meant to happen here. [avagin@openvz.org: use wake_up() instead of wake_up_interruptible] Link: http://lkml.kernel.org/r/20180331022839.21277-1-avagin@openvz.org Link: http://lkml.kernel.org/r/20180319191609.23880-1-willy@infradead.orgSigned-off-by:
Matthew Wilcox <mawilcox@microsoft.com> Acked-by:
Ian Kent <raven@themaw.net> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Aaro Koskinen authored
Use pr_cont() at the end of ramdisk loading. This will avoid the rotator and an extra newline appearing in the dmesg. Before: RAMDISK: Loading 2436KiB [1 disk] into ram disk... | done. After: RAMDISK: Loading 2436KiB [1 disk] into ram disk... done. Link: http://lkml.kernel.org/r/20180302205552.16031-1-aaro.koskinen@iki.fiSigned-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Reviewed-by:
-
Joe Perches authored
Using bool in a bitfield isn't a good idea as the alignment behavior is arch implementation defined. Suggest using unsigned int or u<8|16|32> instead. Link: http://lkml.kernel.org/r/e22fb871b1b7f2fda4b22f3a24e0d7f092eb612c.camel@perches.comSigned-off-by:
Joe Perches <joe@perches.com> Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Heinrich Schuchardt authored
Allow a space between a colon and subsequent opening bracket. This sequence may occur in inline assembler statements like asm( "ldr %[out], [%[in]]\n\t" : [out] "=r" (ret) : [in] "r" (addr) ); Link: http://lkml.kernel.org/r/20180403191655.23700-1-xypron.glpk@gmx.deSigned-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by:
-
Joe Perches authored
Kernel style seems to prefer line wrapping an assignment with the assignment operator on the previous line like: <leading tabs> identifier = expression; over <leading tabs> identifier = expression; somewhere around a 50:1 ratio $ git grep -P "[^=]=\s*$" -- "*.[ch]" | wc -l 52008 $ git grep -P "^\s+[\*\/\+\|\%\-]?=[^=>]" | wc -l 1161 So add a --strict test for that condition. Link: http://lkml.kernel.org/r/1522275726.2210.12.camel@perches.comSigned-off-by:
-
Joe Perches authored
There are occasions where symbolic perms are used in a ternary like return (channel == 0) ? S_IRUGO | S_IWUSR : S_IRUGO; The current test will find the first use "S_IRUGO | S_IWUSR" but not the second use "S_IRUGO" on the same line. Improve the test to look for all instances on a line. Link: http://lkml.kernel.org/r/1522127944.12357.49.camel@perches.comSigned-off-by:
-
Claudio Fontana authored
completly -> completely wacking -> whacking Link: http://lkml.kernel.org/r/1520405394-5586-1-git-send-email-claudio.fontana@gliwa.comSigned-off-by:
Claudio Fontana <claudio.fontana@gliwa.com> Acked-by:
-
Joe Perches authored
The get_quoted_string function does not expect invalid arguments. The $stat test can return non-statements for complicated macros like TRACE_EVENT. Allow the $stat block and test for vsprintf misuses to exceed the actual block length and possibly test invalid lines by validating the arguments of get_quoted_string. Return "" if either get_quoted_string argument is undefined. Miscellanea: o Properly align the comment for the vsprintf extension test Link: http://lkml.kernel.org/r/9e9725342ca3dfc0f5e3e0b8ca3c482b0e5712cc.1520356392.git.joe@perches.comSigned-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Tobin C. Harding authored
Usage of the new %px specifier potentially leaks sensitive information. Printing kernel addresses exposes the kernel layout in memory, this is potentially exploitable. We have tools in the kernel to help us do the right thing. We can have checkpatch warn developers of potential dangers of using %px. Have checkpatch emit a warning for usage of specifier %px. Link: http://lkml.kernel.org/r/1519700648-23108-5-git-send-email-me@tobin.ccSigned-off-by:
Tobin C. Harding <me@tobin.cc> Signed-off-by:
-
Tobin C. Harding authored
checkpatch currently contains duplicate code. We can define a sub routine and call that instead. This reduces code duplication and line count. Add subroutine get_stat_here(). Link: http://lkml.kernel.org/r/1519700648-23108-4-git-send-email-me@tobin.ccSigned-off-by:
-
Tobin C. Harding authored
Variables are declared and not used, we should remove them. Link: http://lkml.kernel.org/r/1519700648-23108-3-git-send-email-me@tobin.ccSigned-off-by:
-
Tobin C. Harding authored
checkpatch currently contains duplicate code. We can define a sub routine and call that instead. This reduces code duplication and line count. Add subroutine get_stat_real() Link: http://lkml.kernel.org/r/1519700648-23108-2-git-send-email-me@tobin.ccSigned-off-by:
-
Gilad Ben-Yossef authored
Add the crypto API *_ON_STACK to $declaration_macros. Resolves the following false warning: WARNING: Missing a blank line after declarations + int err; + SHASH_DESC_ON_STACK(desc, ctx_p->shash_tfm); Link: http://lkml.kernel.org/r/1518941636-4484-1-git-send-email-gilad@benyossef.comSigned-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Rob Herring authored
Add SPDX license tag check based on the rules defined in Documentation/process/license-rules.rst. To summarize, SPDX license tags should be on the 1st line (or 2nd line in scripts) using the appropriate comment style for the file type. Link: http://lkml.kernel.org/r/20180202154026.15298-1-robh@kernel.orgSigned-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Philippe Ombredanne <pombredanne@nexb.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Joe Perches <joe@perches.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Igor Stoppa <igor.stoppa@huawei.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Joe Perches authored
Bare email addresses with non alphanumeric characters require escape quoting before being substituted in the parse_email routine. e.g. Reported-by: syzbot+bbd8e9a06452cc48059b@syzkaller.appspotmail.com Do so. Link: http://lkml.kernel.org/r/1518631805.3678.12.camel@perches.comSigned-off-by:
-
Matthew Wilcox authored
The entire point of printing the pointers in list_debug is to see if there's any useful information in them (eg poison values, ASCII, etc); obscuring them to see if they compare equal makes them much less useful. If an attacker can force this message to be printed, we've already lost. Link: http://lkml.kernel.org/r/20180401223237.GV13332@bombadil.infradead.orgSigned-off-by:
-
Colin Ian King authored
test_ubsan_misaligned_access() is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: lib/test_ubsan.c:91:6: warning: symbol 'test_ubsan_misaligned_access' was not declared. Should it be static? Link: http://lkml.kernel.org/r/20180313103048.28513-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Cc: Jinbum Park <jinb.park7@gmail.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Jinbum Park authored
This is a test module for UBSAN. It triggers all undefined behaviors that linux supports now, and detect them. All test-cases have passed by compiling with gcc-5.5.0. If use gcc-4.9.x, misaligned, out-of-bounds, object-size-mismatch will not be detected. Because gcc-4.9.x doesn't support them. Link: http://lkml.kernel.org/r/20180309102247.GA2944@pjb1027-Latitude-E5410Signed-off-by:
Jinbum Park <jinb.park7@gmail.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
This avoids an accidental stack VLA (since the compiler thinks the value of "len" can change, even when marked "const"). This just replaces it with a #define so it will DTRT. Seen with -Wvla. Fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621 Link: http://lkml.kernel.org/r/20180307212555.GA17927@beastSigned-off-by:
-
Randy Dunlap authored
Keep all of the SOFTLOCKUP kconfig symbols together (instead of injecting the HARDLOCKUP symbols in the midst of them) so that the config tools display them with their dependencies. Tested with 'make {menuconfig/nconfig/gconfig/xconfig}'. Link: http://lkml.kernel.org/r/6be2d9ed-4656-5b94-460d-7f051e2c7570@infradead.org Fixes: 05a4a952 ("kernel/watchdog: split up config options") Signed-off-by: -
Alexandre Bounine authored
Link: http://lkml.kernel.org/r/1522958149-6157-1-git-send-email-alex.bou9@gmail.comSigned-off-by:
-
Kees Cook authored
The original intent for always adding the anonymous struct in task_struct was to make sure we had compiler coverage. However, this caused pathological padding of 40 bytes at the start of task_struct. Instead, move the anonymous struct to being only used when struct layout randomization is enabled. Link: http://lkml.kernel.org/r/20180327213609.GA2964@beast Fixes: 29e48ce8 ("task_struct: Allow randomized") Signed-off-by:
-
Miguel Ojeda authored
clang-format is a tool to format C/C++/... code according to a set of rules and heuristics. Like most tools, it is not perfect nor covers every single case, but it is good enough to be helpful. In particular, it is useful for quickly re-formatting blocks of code automatically, for reviewing full files in order to spot coding style mistakes, typos and possible improvements. It is also handy for sorting ``#includes``, for aligning variables and macros, for reflowing text and other similar tasks. It also serves as a teaching tool/guide for newcomers. The tool itself has been already included in the repositories of popular Linux distributions for a long time. The rules in this file are intended for clang-format >= 4, which is easily available in most distributions. This commit adds the configuration file that contains the rules that the tool uses to know how to format the code according to the kernel coding style. This gives us several advantages: * clang-format works out of the box with reasonable defaults; avoiding that everyone has to re-do the configuration. * Everyone agrees (eventually) on what is the most useful default configuration for most of the kernel. * If it becomes commonplace among kernel developers, clang-format may feel compelled to support us better. They already recognize the Linux kernel and its style in their documentation and in one of the style sub-options. Some of clang-format's features relevant for the kernel are: * Uses clang's tooling support behind the scenes to parse and rewrite the code. It is not based on ad-hoc regexps. * Supports reasonably well the Linux kernel coding style. * Fast enough to be used at the press of a key. * There are already integrations (either built-in or third-party) for many common editors used by kernel developers (e.g. vim, emacs, Sublime, Atom...) that allow you to format an entire file or, more usefully, just your selection. * Able to parse unified diffs -- you can, for instance, reformat only the lines changed by a git commit. * Able to reflow text comments as well. * Widely supported and used by hundreds of developers in highly complex projects and organizations (e.g. the LLVM project itself, Chromium, WebKit, Google, Mozilla...). Therefore, it will be supported for a long time. See more information about the tool at: https://clang.llvm.org/docs/ClangFormat.html https://clang.llvm.org/docs/ClangFormatStyleOptions.html Link: http://lkml.kernel.org/r/20180318171632.qfkemw3mwbcukth6@gmail.comSigned-off-by:Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Joe Perches <joe@perches.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Alexey Dobriyan authored
So "struct uts_namespace" can enjoy fine-grained SLAB debugging and usercopy protection. I'd prefer shorter name "utsns" but there is "user_namespace" already. Link: http://lkml.kernel.org/r/20180228215158.GA23146@avx2Signed-off-by:
-
Kees Cook authored
Since the randstruct plugin can intentionally produce extremely unusual kernel structure layouts (even performance pathological ones), some maintainers want to be able to trivially determine if an Oops is coming from a randstruct-built kernel, so as to keep their sanity when debugging. This adds the new flag and initializes taint_mask immediately when built with randstruct. Link: http://lkml.kernel.org/r/1519084390-43867-4-git-send-email-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
This consolidates the taint bit documentation into a single place with both numeric and letter values. Additionally adds the missing TAINT_AUX documentation. Link: http://lkml.kernel.org/r/1519084390-43867-3-git-send-email-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
This converts to using indexed initializers instead of comments, adds a comment on why the taint flags can't be an enum, and make sure that no one forgets to update the taint_flags when adding new bits. Link: http://lkml.kernel.org/r/1519084390-43867-2-git-send-email-keescook@chromium.orgSigned-off-by:
-
Alexey Dobriyan authored
The only tests I could come up with for /proc/uptime are: - test that values increase monotonically for 1 second, - bounce around CPUs and test the same thing. Avoid glibc like plague for affinity given patches like this: https://marc.info/?l=linux-kernel&m=152130031912594&w=4 Link: http://lkml.kernel.org/r/20180317165235.GB3445@avx2Signed-off-by:
-
Alexey Dobriyan authored
In a typical for /proc "open+read+close" usecase, dentry is looked up successfully on open only to be killed in dput() on close. In fact dentries which aren't /proc/*/... and /proc/sys/* were almost NEVER CACHED. Simple printk in proc_lookup_de() shows that. Now that ->delete hook intelligently picks which dentries should live in dcache and which should not, rbtree caching is not necessary as dcache does it job, at last! As a side effect, struct proc_dir_entry shrinks by one pointer which can go into inline name. Link: http://lkml.kernel.org/r/20180314231032.GA15854@avx2Signed-off-by:
Davidlohr Bueso <dbueso@suse.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Alexey Dobriyan authored
Perform reads with nearly everything in /proc, and some writing as well. Hopefully memleak checkers and KASAN will find something. [adobriyan@gmail.com: /proc/kmsg can and will block if read under root] Link: http://lkml.kernel.org/r/20180316232147.GA20146@avx2Signed-off-by:
-
