- 14 Nov, 2014 40 commits
-
-
Alex Williamson authored
commit 25b11ce2 upstream. For a PCI device, aliases from the IVRS table won't be populated into dma_alias_devfn until after iommu_init_device() is called on each device. We therefore want to split init_iommu_group() to be called from a separate loop immediately following. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alex Williamson authored
commit f096c061 upstream. It turns out that our assumption that aliases are always to the same slot isn't true. One particular platform reports an IVRS alias of the SATA controller (00:11.0) for the legacy IDE controller (00:14.1). When we hit this, we attempt to use a single IOMMU group for everything on the same bus, which in this case is the root complex. We already have multiple groups defined for the root complex by this point, resulting in multiple WARN_ON hits. This patch makes these sorts of aliases work again with IOMMU groups by reworking how we search through the PCI address space to find existing groups. This should also now handle looped dependencies and all sorts of crazy inter-dependencies that we'll likely never see. The recursion used here should never be very deep. It's unlikely to have individual aliases and only theoretical that we'd ever see a chain where one alias causes us to search through to yet another alias. We're also only dealing with PCIe device on a single bus, which means we'll typically only see multiple slots in use on the root complex. Loops are also a theoretically possibility, which I've tested using fake DMA alias quirks and prevent from causing problems using a bitmap of the devfn space that's been visited. Signed-off-by:
-
Chris Ball authored
commit 51529705 upstream. pci_enable_msi() can return failure with both positive and negative integers -- it returns 0 for success -- but is only tested here for "if (ret < 0)". This causes us to try to use MSI on the RTS5249 SD reader in the Dell XPS 11 when enabling MSI failed, causing: [ 1.737110] rtsx_pci: probe of 0000:05:00.0 failed with error -110 Reported-by:
D. Jared Dominguez <Jared_Dominguez@Dell.com> Tested-by:
Chris Ball <chris@printf.net> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 6a71f38d upstream. In the resume path, the ADC invokes am335x_tsc_se_set_cache() with 0 as the steps argument if continous mode is not in use. This in turn disables all steps and so the TSC is not working until one ADC sampling is performed. This patch fixes it by writing the current cached mask instead of the passed steps. Fixes: 7ca6740c ("mfd: input: iio: ti_amm335x: Rework TSC/ADCA synchronization") Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Vignesh R authored
commit 6ac734d2 upstream. After enabling and disabling ADC continuous mode via sysfs, ts_print_raw fails to return any data. This is because when ADC is configured for continuous mode, it disables touch screen steps.These steps are not re-enabled when ADC continuous mode is disabled. Therefore existing values of REG_SE needs to be cached before enabling continuous mode and disabling touch screen steps and enabling ADC steps. The cached value are to be restored to REG_SE once ADC is disabled. Fixes: 7ca6740c ("mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization") Signed-off-by:
Vignesh R <vigneshr@ti.com> Signed-off-by:
-
Eric W. Biederman authored
commit 0d082601 upstream. Andy Lutomirski recently demonstrated that when chroot is used to set the root path below the path for the new ``root'' passed to pivot_root the pivot_root system call succeeds and leaks mounts. In examining the code I see that starting with a new root that is below the current root in the mount tree will result in a loop in the mount tree after the mounts are detached and then reattached to one another. Resulting in all kinds of ugliness including a leak of that mounts involved in the leak of the mount loop. Prevent this problem by ensuring that the new mount is reachable from the current root of the mount tree. [Added stable cc. Fixes CVE-2014-7970. --Andy] Reported-by:
Andy Lutomirski <luto@amacapital.net> Reviewed-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Richard Genoud authored
commit 1bf1890e upstream. I ran into this error after a ubiupdatevol, because I forgot to backport e9110361 UBI: fix the volumes tree sorting criteria. UBI error: process_pool_aeb: orphaned volume in fastmap pool UBI error: ubi_scan_fastmap: Attach by fastmap failed, doing a full scan! kmem_cache_destroy ubi_ainf_peb_slab: Slab cache still has objects CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.18-00053-gf05cac8dbf85 #1 [<c000d298>] (unwind_backtrace) from [<c000baa8>] (show_stack+0x10/0x14) [<c000baa8>] (show_stack) from [<c01b7a68>] (destroy_ai+0x230/0x244) [<c01b7a68>] (destroy_ai) from [<c01b8fd4>] (ubi_attach+0x98/0x1ec) [<c01b8fd4>] (ubi_attach) from [<c01ade90>] (ubi_attach_mtd_dev+0x2b8/0x868) [<c01ade90>] (ubi_attach_mtd_dev) from [<c038b510>] (ubi_init+0x1dc/0x2ac) [<c038b510>] (ubi_init) from [<c0008860>] (do_one_initcall+0x94/0x140) [<c0008860>] (do_one_initcall) from [<c037aadc>] (kernel_init_freeable+0xe8/0x1b0) [<c037aadc>] (kernel_init_freeable) from [<c02730ac>] (kernel_init+0x8/0xe4) [<c02730ac>] (kernel_init) from [<c00093f0>] (ret_from_fork+0x14/0x24) UBI: scanning is finished Freeing the cache in the error path fixes the Slab error. Tested on at91sam9g35 (3.14.18+fastmap backports) Signed-off-by:
Richard Genoud <richard.genoud@gmail.com> Signed-off-by:
-
Ezequiel Garcia authored
commit fda322a1 upstream. The UBI_IOCVOLUP ioctl is used to start an update and also to truncate a volume. In the first case, a "volume updated" notification is dispatched when the update is done. This commit adds the "volume updated" notification to be also sent when the volume is truncated. This is required for UBI block and gluebi to get notified about the new volume size. Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
-
Ezequiel Garcia authored
commit 06d9c290 upstream. Static volumes can change its 'used_bytes' when they get updated, and so the block interface must listen to the UBI_VOLUME_UPDATED notification to resize the block device accordingly. Signed-off-by:
-
Ezequiel Garcia authored
commit 978d6496 upstream. We are currently taking the block device size from the ubi_volume_info.size field. However, this is not the amount of data in the volume, but the number of reserved physical eraseblocks, and hence leads to an incorrect representation of the volume. In particular, this produces I/O errors on static volumes as the block interface may attempt to read unmapped PEBs: $ cat /dev/ubiblock0_0 > /dev/null UBI error: ubiblock_read_to_buf: ubiblock0_0 ubi_read error -22 end_request: I/O error, dev ubiblock0_0, sector 9536 Buffer I/O error on device ubiblock0_0, logical block 2384 [snip] Fix this by using the ubi_volume_info.used_bytes field which is set to the actual number of data bytes for both static and dynamic volumes. While here, improve the error message to be less stupid and more useful: UBI error: ubiblock_read_to_buf: ubiblock0_1 ubi_read error -9 on LEB=0, off=15872, len=512 It's worth noticing that the 512-byte sector representation of the volume is only correct if the volume size is multiple of 512-bytes. This is true for virtually any NAND device, given eraseblocks and pages are 512-byte multiple and hence so is the LEB size. Artem: tweak the error message and make it look more like other UBI error messages. Fixes: 9d54c8a3 ("UBI: R/O block driver on top of UBI volumes") Signed-off-by:
-
Martin Schwidefsky authored
commit 48e9a6c1 upstream. The call to topology_init is too late for the set_sched_topology call. The initial scheduling domain structure has already been established with default topology array. Use the smp_cpus_done() call to get the s390 specific topology array registered early enough. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Daniel Borkmann authored
commit d4c5efdb upstream. zatimend has reported that in his environment (3.16/gcc4.8.3/corei7) memset() calls which clear out sensitive data in extract_{buf,entropy, entropy_user}() in random driver are being optimized away by gcc. Add a helper memzero_explicit() (similarly as explicit_bzero() variants) that can be used in such cases where a variable with sensitive data is being cleared out in the end. Other use cases might also be in crypto code. [ I have put this into lib/string.c though, as it's always built-in and doesn't need any dependencies then. ] Fixes kernel bugzilla: 82041 Reported-by: zatimend@hotmail.co.uk Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Thorsten Knabe authored
commit 2a236122 upstream. Starting with Linux 3.12 processes get stuck in D state forever in UserModeLinux under sync heavy workloads. This bug was introduced by commit 805f11a0 (um: ubd: Add REQ_FLUSH suppport). Fix bug by adding a check if FLUSH request was successfully submitted to the I/O thread and keeping the FLUSH request on the request queue on submission failures. Fixes: 805f11a0 (um: ubd: Add REQ_FLUSH suppport) Signed-off-by:
Thorsten Knabe <linux@thorsten-knabe.de> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Kirill Tkhai authored
commit 66339c31 upstream. dl_bw_of() dereferences rq->rd which has to have RCU read lock held. Probability of use-after-free isn't zero here. Also add lockdep assert into dl_bw_cpus(). Signed-off-by:
Kirill Tkhai <ktkhai@parallels.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20140922183624.11015.71558.stgit@localhostSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Ilya Dryomov authored
commit f9865f06 upstream. Commit f363e45f ("net/ceph: make ceph_msgr_wq non-reentrant") effectively removed WQ_MEM_RECLAIM flag from ceph_msgr_wq. This is wrong - libceph is very much a memory reclaim path, so restore it. Signed-off-by:
Ilya Dryomov <idryomov@redhat.com> Tested-by:
Micha Krause <micha@krausam.de> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
-
Ilya Dryomov authored
commit 792c3a91 upstream. Need to use WQ_MEM_RECLAIM for our workqueues to prevent I/O lockups under memory pressure - we sit on the memory reclaim path. Signed-off-by:
-
Al Viro authored
commit 24dff96a upstream. we used to check for "nobody else could start doing anything with that opened file" by checking that refcount was 2 or less - one for descriptor table and one we'd acquired in fget() on the way to wherever we are. That was race-prone (somebody else might have had a reference to descriptor table and do fget() just as we'd been checking) and it had become flat-out incorrect back when we switched to fget_light() on those codepaths - unlike fget(), it doesn't grab an extra reference unless the descriptor table is shared. The same change allowed a race-free check, though - we are safe exactly when refcount is less than 2. It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading to ppp one) and 2.6.17 for sendmsg() (netlink one). OTOH, netlink hadn't grown that check until 3.9 and ppp used to live in drivers/net, not drivers/net/ppp until 3.1. The bug existed well before that, though, and the same fix used to apply in old location of file. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
commit 99358a1c upstream. schedule_delayed_work() happening when the work is already pending is a cheap no-op. Don't bother with ->wbuf_queued logics - it's both broken (cancelling ->wbuf_dwork leaves it set, as spotted by Jeff Harris) and pointless. It's cheaper to let schedule_delayed_work() handle that case. Reported-by:
Jeff Harris <jefftharris@gmail.com> Tested-by:
-
Al Viro authored
commit 6d13f694 upstream. AFAICS, prepend_name() is broken on SMP alpha. Disclaimer: I don't have SMP alpha boxen to reproduce it on. However, it really looks like the race is real. CPU1: d_path() on /mnt/ramfs/<255-character>/foo CPU2: mv /mnt/ramfs/<255-character> /mnt/ramfs/<63-character> CPU2 does d_alloc(), which allocates an external name, stores the name there including terminating NUL, does smp_wmb() and stores its address in dentry->d_name.name. It proceeds to d_add(dentry, NULL) and d_move() old dentry over to that. ->d_name.name value ends up in that dentry. In the meanwhile, CPU1 gets to prepend_name() for that dentry. It fetches ->d_name.name and ->d_name.len; the former ends up pointing to new name (64-byte kmalloc'ed array), the latter - 255 (length of the old name). Nothing to force the ordering there, and normally that would be OK, since we'd run into the terminating NUL and stop. Except that it's alpha, and we'd need a data dependency barrier to guarantee that we see that store of NUL __d_alloc() has done. In a similar situation dentry_cmp() would survive; it does explicit smp_read_barrier_depends() after fetching ->d_name.name. prepend_name() doesn't and it risks walking past the end of kmalloc'ed object and possibly oops due to taking a page fault in kernel mode. Signed-off-by:
-
Takashi Iwai authored
commit 317168d0 upstream. In compat mode, we copy each field of snd_pcm_status struct but don't touch the reserved fields, and this leaves uninitialized values there. Meanwhile the native ioctl does zero-clear the whole structure, so we should follow the same rule in compat mode, too. Reported-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Christian Vogel authored
commit d1d0b6b6 upstream. snd_bebob_stream_check_internal_clock() may get an id from saffirepro_both_clk_src_get (via clk_src->get()) that was uninitialized. a) make logic in saffirepro_both_clk_src_get explicit b) test if id used in snd_bebob_stream_check_internal_clock matches array size [fixed missing signed prefix to *_maps[] by tiwai] Signed-off-by:
Christian Vogel <vogelchr@vogel.cx> Reviewed-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
Takashi Iwai authored
commit 3b70bdba upstream. CMI8888 shows the stuttering playback when the snooping is disabled on the audio buffer. Meanwhile, we've got reports that CORB/RIRB doesn't work in the snooped mode. So, as a compromise, disable the snoop only for CORB/RIRB and enable the snoop for the stream buffers. The resultant patch became a bit ugly, unfortunately, but we still can live with it. Reported-and-tested-by:
Geoffrey McRae <geoff@spacevs.com> Signed-off-by:
-
Dmitry Kasatkin authored
commit 3b1deef6 upstream. evm_inode_setxattr() can be called with no value. The function does not check the length so that following command can be used to produce the kernel oops: setfattr -n security.evm FOO. This patch fixes it. Changes in v3: * there is no reason to return different error codes for EVM_XATTR_HMAC and non EVM_XATTR_HMAC. Remove unnecessary test then. Changes in v2: * testing for validity of xattr type [ 1106.396921] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1106.398192] IP: [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48 [ 1106.399244] PGD 29048067 PUD 290d7067 PMD 0 [ 1106.399953] Oops: 0000 [#1] SMP [ 1106.400020] Modules linked in: bridge stp llc evdev serio_raw i2c_piix4 button fuse [ 1106.400020] CPU: 0 PID: 3635 Comm: setxattr Not tainted 3.16.0-kds+ #2936 [ 1106.400020] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 1106.400020] task: ffff8800291a0000 ti: ffff88002917c000 task.ti: ffff88002917c000 [ 1106.400020] RIP: 0010:[<ffffffff812af7b8>] [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48 [ 1106.400020] RSP: 0018:ffff88002917fd50 EFLAGS: 00010246 [ 1106.400020] RAX: 0000000000000000 RBX: ffff88002917fdf8 RCX: 0000000000000000 [ 1106.400020] RDX: 0000000000000000 RSI: ffffffff818136d3 RDI: ffff88002917fdf8 [ 1106.400020] RBP: ffff88002917fd68 R08: 0000000000000000 R09: 00000000003ec1df [ 1106.400020] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800438a0a00 [ 1106.400020] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 1106.400020] FS: 00007f7dfa7d7740(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000 [ 1106.400020] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1106.400020] CR2: 0000000000000000 CR3: 000000003763e000 CR4: 00000000000006f0 [ 1106.400020] Stack: [ 1106.400020] ffff8800438a0a00 ffff88002917fdf8 0000000000000000 ffff88002917fd98 [ 1106.400020] ffffffff812a1030 ffff8800438a0a00 ffff88002917fdf8 0000000000000000 [ 1106.400020] 0000000000000000 ffff88002917fde0 ffffffff8116d08a ffff88002917fdc8 [ 1106.400020] Call Trace: [ 1106.400020] [<ffffffff812a1030>] security_inode_setxattr+0x5d/0x6a [ 1106.400020] [<ffffffff8116d08a>] vfs_setxattr+0x6b/0x9f [ 1106.400020] [<ffffffff8116d1e0>] setxattr+0x122/0x16c [ 1106.400020] [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45 [ 1106.400020] [<ffffffff8114d011>] ? __sb_start_write+0x10f/0x143 [ 1106.400020] [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45 [ 1106.400020] [<ffffffff811687c0>] ? __mnt_want_write+0x48/0x4f [ 1106.400020] [<ffffffff8116d3e6>] SyS_setxattr+0x6e/0xb0 [ 1106.400020] [<ffffffff81529da9>] system_call_fastpath+0x16/0x1b [ 1106.400020] Code: c3 0f 1f 44 00 00 55 48 89 e5 41 55 49 89 d5 41 54 49 89 fc 53 48 89 f3 48 c7 c6 d3 36 81 81 48 89 df e8 18 22 04 00 85 c0 75 07 <41> 80 7d 00 02 74 0d 48 89 de 4c 89 e7 e8 5a fe ff ff eb 03 83 [ 1106.400020] RIP [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48 [ 1106.400020] RSP <ffff88002917fd50> [ 1106.400020] CR2: 0000000000000000 [ 1106.428061] ---[ end trace ae08331628ba3050 ]--- Reported-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Signed-off-by:
-
Dmitry Kasatkin authored
commit 3dcbad52 upstream. Unless an LSM labels a file during d_instantiate(), newly created files are not labeled with an initial security.evm xattr, until the file closes. EVM, before allowing a protected, security xattr to be written, verifies the existing 'security.evm' value is good. For newly created files without a security.evm label, this verification prevents writing any protected, security xattrs, until the file closes. Following is the example when this happens: fd = open("foo", O_CREAT | O_WRONLY, 0644); setxattr("foo", "security.SMACK64", value, sizeof(value), 0); close(fd); While INTEGRITY_NOXATTRS status is handled in other places, such as evm_inode_setattr(), it does not handle it in all cases in evm_protect_xattr(). By limiting the use of INTEGRITY_NOXATTRS to newly created files, we can now allow setting "protected" xattrs. Changelog: - limit the use of INTEGRITY_NOXATTRS to IMA identified new files Signed-off-by:
-
Peter Zijlstra authored
commit 211de6eb upstream. The idiot who did 4a1c0f26 ("perf: Fix lockdep warning on process exit") forgot to pay attention and fix all similar cases. Do so now. In particular, unclone_ctx() must be called while holding ctx->lock, therefore all such sites are broken for the same reason. Pull the put_ctx() call out from under ctx->lock. Reported-by:
Sasha Levin <sasha.levin@oracle.com> Probably-also-reported-by:
Vince Weaver <vincent.weaver@maine.edu> Fixes: 4a1c0f26 ("perf: Fix lockdep warning on process exit") Signed-off-by:
-
Dexuan Cui authored
commit d1cd1210 upstream. pte_pfn() returns a PFN of long (32 bits in 32-PAE), so "long << PAGE_SHIFT" will overflow for PFNs above 4GB. Due to this issue, some Linux 32-PAE distros, running as guests on Hyper-V, with 5GB memory assigned, can't load the netvsc driver successfully and hence the synthetic network device can't work (we can use the kernel parameter mem=3000M to work around the issue). Cast pte_pfn() to phys_addr_t before shifting. Fixes: "commit d7656534: x86, mm: Create slow_virt_to_phys()" Signed-off-by:
Dexuan Cui <decui@microsoft.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: gregkh@linuxfoundation.org Cc: linux-mm@kvack.org Cc: olaf@aepfle.de Cc: apw@canonical.com Cc: jasowang@redhat.com Cc: dave.hansen@intel.com Cc: riel@redhat.com Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1414580017-27444-1-git-send-email-decui@microsoft.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Andy Lutomirski authored
commit 653bc77a upstream. Rusty noticed a Really Bad Bug (tm) in my NT fix. The entry code reads out of bounds, causing the NT fix to be unreliable. But, and this is much, much worse, if your stack is somehow just below the top of the direct map (or a hole), you read out of bounds and crash. Excerpt from the crash: [ 1.129513] RSP: 0018:ffff88001da4bf88 EFLAGS: 00010296 2b:* f7 84 24 90 00 00 00 testl $0x4000,0x90(%rsp) That read is deterministically above the top of the stack. I thought I even single-stepped through this code when I wrote it to check the offset, but I clearly screwed it up. Fixes: 8c7aa698 ("x86_64, entry: Filter RFLAGS.NT on entry from userspace") Reported-by:
Rusty Russell <rusty@ozlabs.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Andy Lutomirski authored
commit 8c7aa698 upstream. The NT flag doesn't do anything in long mode other than causing IRET to #GP. Oddly, CPL3 code can still set NT using popf. Entry via hardware or software interrupt clears NT automatically, so the only relevant entries are fast syscalls. If user code causes kernel code to run with NT set, then there's at least some (small) chance that it could cause trouble. For example, user code could cause a call to EFI code with NT set, and who knows what would happen? Apparently some games on Wine sometimes do this (!), and, if an IRET return happens, they will segfault. That segfault cannot be handled, because signal delivery fails, too. This patch programs the CPU to clear NT on entry via SYSCALL (both 32-bit and 64-bit, by my reading of the AMD APM), and it clears NT in software on entry via SYSENTER. To save a few cycles, this borrows a trick from Jan Beulich in Xen: it checks whether NT is set before trying to clear it. As a result, it seems to have very little effect on SYSENTER performance on my machine. There's another minor bug fix in here: it looks like the CFI annotations were wrong if CONFIG_AUDITSYSCALL=n. Testers beware: on Xen, SYSENTER with NT set turns into a GPF. I haven't touched anything on 32-bit kernels. The syscall mask change comes from a variant of this patch by Anish Bhatt. Note to stable maintainers: there is no known security issue here. A misguided program can set NT and cause the kernel to try and fail to deliver SIGSEGV, crashing the program. This patch fixes Far Cry on Wine: https://bugs.winehq.org/show_bug.cgi?id=33275Reported-by:
Anish Bhatt <anish@chelsio.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Oleg Nesterov authored
commit 66463db4 upstream. save_xstate_sig()->drop_init_fpu() doesn't look right. setup_rt_frame() can fail after that, in this case the next setup_rt_frame() triggered by SIGSEGV won't save fpu simply because the old state was lost. This obviously mean that fpu won't be restored after sys_rt_sigreturn() from SIGSEGV handler. Shift drop_init_fpu() into !failed branch in handle_signal(). Test-case (needs -O2): #include <stdio.h> #include <signal.h> #include <unistd.h> #include <sys/syscall.h> #include <sys/mman.h> #include <pthread.h> #include <assert.h> volatile double D; void test(double d) { int pid = getpid(); for (D = d; D == d; ) { /* sys_tkill(pid, SIGHUP); asm to avoid save/reload * fp regs around "C" call */ asm ("" : : "a"(200), "D"(pid), "S"(1)); asm ("syscall" : : : "ax"); } printf("ERR!!\n"); } void sigh(int sig) { } char altstack[4096 * 10] __attribute__((aligned(4096))); void *tfunc(void *arg) { for (;;) { mprotect(altstack, sizeof(altstack), PROT_READ); mprotect(altstack, sizeof(altstack), PROT_READ|PROT_WRITE); } } int main(void) { stack_t st = { .ss_sp = altstack, .ss_size = sizeof(altstack), .ss_flags = SS_ONSTACK, }; struct sigaction sa = { .sa_handler = sigh, }; pthread_t pt; sigaction(SIGSEGV, &sa, NULL); sigaltstack(&st, NULL); sa.sa_flags = SA_ONSTACK; sigaction(SIGHUP, &sa, NULL); pthread_create(&pt, NULL, tfunc, NULL); test(123.456); return 0; } Reported-by:
Bean Anderson <bean@azulsystems.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Link: http://lkml.kernel.org/r/20140902175713.GA21646@redhat.comSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Oleg Nesterov authored
commit df24fb85 upstream. Add preempt_disable() + preempt_enable() around math_state_restore() in __restore_xstate_sig(). Otherwise __switch_to() after __thread_fpu_begin() can overwrite fpu->state we are going to restore. Signed-off-by:
Suresh Siddha <sbsiddha@gmail.com> Signed-off-by:
-
Ben Hutchings authored
commit 0e6d3112 upstream. It is currently possible to execve() an x32 executable on an x86_64 kernel that has only ia32 compat enabled. However all its syscalls will fail, even _exit(). This usually causes it to segfault. Change the ELF compat architecture check so that x32 executables are rejected if we don't support the x32 ABI. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Link: http://lkml.kernel.org/r/1410120305.6822.9.camel@decadent.org.ukSigned-off-by:
-
Jan Kara authored
commit 90a80202 upstream. ->page_mkwrite() is used by filesystems to allocate blocks under a page which is becoming writeably mmapped in some process' address space. This allows a filesystem to return a page fault if there is not enough space available, user exceeds quota or similar problem happens, rather than silently discarding data later when writepage is called. However VFS fails to call ->page_mkwrite() in all the cases where filesystems need it when blocksize < pagesize. For example when blocksize = 1024, pagesize = 4096 the following is problematic: ftruncate(fd, 0); pwrite(fd, buf, 1024, 0); map = mmap(NULL, 1024, PROT_WRITE, MAP_SHARED, fd, 0); map[0] = 'a'; ----> page_mkwrite() for index 0 is called ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */ mremap(map, 1024, 10000, 0); map[4095] = 'a'; ----> no page_mkwrite() called At the moment ->page_mkwrite() is called, filesystem can allocate only one block for the page because i_size == 1024. Otherwise it would create blocks beyond i_size which is generally undesirable. But later at ->writepage() time, we also need to store data at offset 4095 but we don't have block allocated for it. This patch introduces a helper function filesystems can use to have ->page_mkwrite() called at all the necessary moments. Signed-off-by:
-
Artem Bityutskiy authored
commit ba29e721 upstream. Hu (hujianyang <hujianyang@huawei.com>) discovered an issue in the 'empty_log_bytes()' function, which calculates how many bytes are left in the log: " If 'c->lhead_lnum + 1 == c->ltail_lnum' and 'c->lhead_offs == c->leb_size', 'h' would equalent to 't' and 'empty_log_bytes()' would return 'c->log_bytes' instead of 0. " At this point it is not clear what would be the consequences of this, and whether this may lead to any problems, but this patch addresses the issue just in case. Tested-by:
hujianyang <hujianyang@huawei.com> Reported-by:
-
Artem Bityutskiy authored
commit 052c2807 upstream. Hu (hujianyang@huawei.com) discovered a race condition which may lead to a situation when UBIFS is unable to mount the file-system after an unclean reboot. The problem is theoretical, though. In UBIFS, we have the log, which basically a set of LEBs in a certain area. The log has the tail and the head. Every time user writes data to the file-system, the UBIFS journal grows, and the log grows as well, because we append new reference nodes to the head of the log. So the head moves forward all the time, while the log tail stays at the same position. At any time, the UBIFS master node points to the tail of the log. When we mount the file-system, we scan the log, and we always start from its tail, because this is where the master node points to. The only occasion when the tail of the log changes is the commit operation. The commit operation has 2 phases - "commit start" and "commit end". The former is relatively short, and does not involve much I/O. During this phase we mostly just build various in-memory lists of the things which have to be written to the flash media during "commit end" phase. During the commit start phase, what we do is we "clean" the log. Indeed, the commit operation will index all the data in the journal, so the entire journal "disappears", and therefore the data in the log become unneeded. So we just move the head of the log to the next LEB, and write the CS node there. This LEB will be the tail of the new log when the commit operation finishes. When the "commit start" phase finishes, users may write more data to the file-system, in parallel with the ongoing "commit end" operation. At this point the log tail was not changed yet, it is the same as it had been before we started the commit. The log head keeps moving forward, though. The commit operation now needs to write the new master node, and the new master node should point to the new log tail. After this the LEBs between the old log tail and the new log tail can be unmapped and re-used again. And here is the possible problem. We do 2 operations: (a) We first update the log tail position in memory (see 'ubifs_log_end_commit()'). (b) And then we write the master node (see the big lock of code in 'do_commit()'). But nothing prevents the log head from moving forward between (a) and (b), and the log head may "wrap" now to the old log tail. And when the "wrap" happens, the contends of the log tail gets erased. Now a power cut happens and we are in trouble. We end up with the old master node pointing to the old tail, which was erased. And replay fails because it expects the master node to point to the correct log tail at all times. This patch merges the abovementioned (a) and (b) operations by moving the master node change code to the 'ubifs_log_end_commit()' function, so that it runs with the log mutex locked, which will prevent the log from being changed benween operations (a) and (b). Reported-by:
-
Eric Rannaud authored
commit 69a91c23 upstream. The man page for open(2) indicates that when O_CREAT is specified, the 'mode' argument applies only to future accesses to the file: Note that this mode applies only to future accesses of the newly created file; the open() call that creates a read-only file may well return a read/write file descriptor. The man page for open(2) implies that 'mode' is treated identically by O_CREAT and O_TMPFILE. O_TMPFILE, however, behaves differently: int fd = open("/tmp", O_TMPFILE | O_RDWR, 0); assert(fd == -1); assert(errno == EACCES); int fd = open("/tmp", O_TMPFILE | O_RDWR, 0600); assert(fd > 0); For O_CREAT, do_last() sets acc_mode to MAY_OPEN only: if (*opened & FILE_CREATED) { /* Don't check for write permission, don't truncate */ open_flag &= ~O_TRUNC; will_truncate = false; acc_mode = MAY_OPEN; path_to_nameidata(path, nd); goto finish_open_created; } But for O_TMPFILE, do_tmpfile() passes the full op->acc_mode to may_open(). This patch lines up the behavior of O_TMPFILE with O_CREAT. After the inode is created, may_open() is called with acc_mode = MAY_OPEN, in do_tmpfile(). A different, but related glibc bug revealed the discrepancy: https://sourceware.org/bugzilla/show_bug.cgi?id=17523 The glibc lazily loads the 'mode' argument of open() and openat() using va_arg() only if O_CREAT is present in 'flags' (to support both the 2 argument and the 3 argument forms of open; same idea for openat()). However, the glibc ignores the 'mode' argument if O_TMPFILE is in 'flags'. On x86_64, for open(), it magically works anyway, as 'mode' is in RDX when entering open(), and is still in RDX on SYSCALL, which is where the kernel looks for the 3rd argument of a syscall. But openat() is not quite so lucky: 'mode' is in RCX when entering the glibc wrapper for openat(), while the kernel looks for the 4th argument of a syscall in R10. Indeed, the syscall calling convention differs from the regular calling convention in this respect on x86_64. So the kernel sees mode = 0 when trying to use glibc openat() with O_TMPFILE, and fails with EACCES. Signed-off-by:
Eric Rannaud <e@nanocritical.com> Acked-by:
-
Tetsuo Handa authored
commit 475d0db7 upstream. total_objects could be 0 and is used as a denom. While total_objects is a "long", total_objects == 0 unlikely happens for 3.12 and later kernels because 32-bit architectures would not be able to hold (1 << 32) objects. However, total_objects == 0 may happen for kernels between 3.1 and 3.11 because total_objects in prune_super() was an "int" and (e.g.) x86_64 architecture might be able to hold (1 << 32) objects. Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Mikulas Patocka authored
commit c2ca0fcd upstream. This patch makes it possible to kill a process looping in cont_expand_zero. A process may spend a lot of time in this function, so it is desirable to be able to kill it. It happened to me that I wanted to copy a piece data from the disk to a file. By mistake, I used the "seek" parameter to dd instead of "skip". Due to the "seek" parameter, dd attempted to extend the file and became stuck doing so - the only possibility was to reset the machine or wait many hours until the filesystem runs out of space and cont_expand_zero fails. We need this patch to be able to terminate the process. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Bartlomiej Zolnierkiewicz authored
commit 221414db upstream. Runtime Power Management handling for the sdhci_add_host() failure case in sdhci_s3c_probe() should match the code in sdhci_s3c_remove() (which uses pm_runtime_disable() call which matches the earlier pm_runtime_enable() one). Fix it. This patch fixes "BUG: spinlock bad magic on CPU#0, swapper/0/1" and "Unbalanced pm_runtime_enable!" warnings. >From the kernel log: ... [ 1.659631] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed [ 1.665096] BUG: spinlock bad magic on CPU#0, swapper/0/1 [ 1.670433] lock: 0xea01e484, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 [ 1.677895] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-next-20140804-00008-ga59480f-dirty #707 [ 1.687037] [<c0013ae4>] (unwind_backtrace) from [<c0010d70>] (show_stack+0x10/0x14) [ 1.694740] [<c0010d70>] (show_stack) from [<c04050c8>] (dump_stack+0x68/0xb8) [ 1.701948] [<c04050c8>] (dump_stack) from [<c0052558>] (do_raw_spin_lock+0x15c/0x1a4) [ 1.709848] [<c0052558>] (do_raw_spin_lock) from [<c040a630>] (_raw_spin_lock_irqsave+0x20/0x28) [ 1.718619] [<c040a630>] (_raw_spin_lock_irqsave) from [<c030d7d0>] (sdhci_do_set_ios+0x1c/0x5cc) [ 1.727464] [<c030d7d0>] (sdhci_do_set_ios) from [<c030ddfc>] (sdhci_runtime_resume_host+0x50/0x104) [ 1.736574] [<c030ddfc>] (sdhci_runtime_resume_host) from [<c02462dc>] (pm_generic_runtime_resume+0x2c/0x40) [ 1.746383] [<c02462dc>] (pm_generic_runtime_resume) from [<c0247898>] (__rpm_callback+0x34/0x70) [ 1.755233] [<c0247898>] (__rpm_callback) from [<c02478fc>] (rpm_callback+0x28/0x88) [ 1.762958] [<c02478fc>] (rpm_callback) from [<c02486f0>] (rpm_resume+0x384/0x4ec) [ 1.770511] [<c02486f0>] (rpm_resume) from [<c02488b0>] (pm_runtime_forbid+0x58/0x64) [ 1.778325] [<c02488b0>] (pm_runtime_forbid) from [<c030ea70>] (sdhci_s3c_probe+0x4a4/0x540) [ 1.786749] [<c030ea70>] (sdhci_s3c_probe) from [<c02429cc>] (platform_drv_probe+0x2c/0x5c) [ 1.795076] [<c02429cc>] (platform_drv_probe) from [<c02415f0>] (driver_probe_device+0x114/0x234) [ 1.803929] [<c02415f0>] (driver_probe_device) from [<c024179c>] (__driver_attach+0x8c/0x90) [ 1.812347] [<c024179c>] (__driver_attach) from [<c023ffb4>] (bus_for_each_dev+0x54/0x88) [ 1.820506] [<c023ffb4>] (bus_for_each_dev) from [<c0240df8>] (bus_add_driver+0xd8/0x1cc) [ 1.828665] [<c0240df8>] (bus_add_driver) from [<c0241db8>] (driver_register+0x78/0xf4) [ 1.836652] [<c0241db8>] (driver_register) from [<c00088a4>] (do_one_initcall+0x80/0x1d0) [ 1.844816] [<c00088a4>] (do_one_initcall) from [<c059ac94>] (kernel_init_freeable+0x108/0x1d4) [ 1.853503] [<c059ac94>] (kernel_init_freeable) from [<c0401300>] (kernel_init+0x8/0xe4) [ 1.861568] [<c0401300>] (kernel_init) from [<c000e538>] (ret_from_fork+0x14/0x3c) [ 1.869582] platform 12530000.sdhci: Driver s3c-sdhci requests probe deferral ... [ 1.997047] s3c-sdhci 12530000.sdhci: Unbalanced pm_runtime_enable! ... [ 2.027235] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed [ 2.032884] platform 12530000.sdhci: Driver s3c-sdhci requests probe deferral ... Tested on Hardkernel's Exynos4412 based ODROID-U3 board. Fixes: 9f4e8151 ("mmc: sdhci-s3c: Enable runtime power management") Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Roger Tseng authored
commit d1419d50 upstream. Current code erroneously fill the last byte of R2 response with an undefined value. In addition, the controller actually 'offloads' the last byte (CRC7, end bit) while receiving R2 response and thus it's impossible to get the actual value. This could cause mmc stack to obtain inconsistent CID from the same card after resume and misidentify it as a different card. Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2. Fixes: ff984e57 ("mmc: Add realtek pcie sdmmc host driver") Signed-off-by:
Roger Tseng <rogerable@realtek.com> Signed-off-by:
-
Stephen Warren authored
commit d4d11449 upstream. As soon as the CD IRQ is requested, it can trigger, since it's an externally controlled event. If it does, delayed_work host->detect will be scheduled. Many host controller probe()s are roughly structured as: *_probe() { host = sdhci_pltfm_init(); mmc_of_parse(host->mmc); rc = sdhci_add_host(host); if (rc) { sdhci_pltfm_free(); return rc; } In 3.17, CD IRQs can are enabled quite early via *_probe() -> mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq(). Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd() rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't call mmc_gpiod_request_cd_irq(). However, this issue still exists if mmc_gpio_request_cd() is called directly before mmc_start_host(). sdhci_add_host() may fail part way through (e.g. due to deferred probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is coded to assume that if sdhci_add_host() failed, then the delayed_work cannot (or should not) have been triggered. This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when kfree(host) is eventually called inside sdhci_pltfm_free(): WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263 debug_print_object+0x8c/0xb4() ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x18 The object being complained about is host->detect. There's no need to request the CD IRQ so early; mmc_start_host() already requests it. For most SDHCI hosts at least, the typical call path that does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() -> mmc_start_host(). Therefore, remove the call to mmc_gpiod_request_cd_irq() from mmc_gpio_request_cd(). This also matches mmc_gpio*d*_request_cd(), which already doesn't call mmc_gpiod_request_cd_irq(). However, some host controller drivers call mmc_gpio_request_cd() after mmc_start_host() has already been called, and assume that this will also call mmc_gpiod_request_cd_irq(). Update those drivers to explicitly call mmc_gpiod_request_cd_irq() themselves. Ideally, these drivers should be modified to move their call to mmc_gpio_request_cd() before their call to mmc_add_host(). However that's too large a change for stable. This solves the problem (eliminates the kernel error message above), since it guarantees that the IRQ can't trigger before mmc_start_host() is called. The critical point here is that once sdhci_add_host() calls mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to fail. In other words, if there's a chance that mmc_start_host() may have been called, and CD IRQs triggered, and the delayed_work scheduled, sdhci_add_host() won't fail, and so cleanup is no longer via sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue) but instead must be via sdhci_remove_host(), which calls mmc_remove_host() -> mmc_stop_host(), which does free the IRQ and cancel the work queue. CC: Russell King <linux@arm.linux.org.uk> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Stephen Warren <swarren@nvidia.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
