- 20 Nov, 2016 15 commits
-
-
Lukas Wunner authored
commit 447d29d1 upstream. Since the following commit: 8659c406 ("x86: only scan the root bus in early PCI quirks") ... early quirks are only applied to devices on the root bus. The motivation was to prevent application of the nvidia_bugs quirk on secondary buses. We're about to reintroduce scanning of secondary buses for a quirk to reset the Broadcom 4331 wireless card on 2011/2012 Macs. To prevent regressions, open code the requirement to apply nvidia_bugs only on the root bus. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/4d5477c1d76b2f0387a780f2142bbcdd9fee869b.1465690253.git.lukas@wunner.deSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
WANG Cong authored
commit 205e1e25 upstream. Matt reported that we have a NULL pointer dereference in ppp_pernet() from ppp_connect_channel(), i.e. pch->chan_net is NULL. This is due to that a parallel ppp_unregister_channel() could happen while we are in ppp_connect_channel(), during which pch->chan_net set to NULL. Since we need a reference to net per channel, it makes sense to sync the refcnt with the life time of the channel, therefore we should release this reference when we destroy it. Fixes: 1f461dcd ("ppp: take reference on channels netns") Reported-by:
Matt Bennett <Matt.Bennett@alliedtelesis.co.nz> Cc: Paul Mackerras <paulus@samba.org> Cc: linux-ppp@vger.kernel.org Cc: Guillaume Nault <g.nault@alphalink.fr> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Takashi Iwai authored
commit f388cdcd upstream. snd_ctl_remove() has a notification for the removal event. It's superfluous when done during the device got disconnected. Although the notification itself is mostly harmless, it may potentially be harmful, and should be suppressed. Actually some components PCM may free ctl elements during the disconnect or free callbacks, thus it's no theoretical issue. This patch adds the check of card->shutdown flag for avoiding unnecessary notifications after (or during) the disconnect. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Lyude authored
commit 14ff8d48 upstream. DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not disconnections. Because of this, we end up losing hotplug polling for analog connectors once they get connected. Easy way to reproduce: - Grab a machine with a radeon GPU and a VGA port - Plug a monitor into the VGA port, wait for it to update the connector from disconnected to connected - Disconnect the monitor on VGA, a hotplug event is never sent for the removal of the connector. Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good idea since doing VGA polling can sometimes result in having to mess with the DAC voltages to figure out whether or not there's actually something there since VGA doesn't have HPD. Doing this would have the potential of showing visible artifacts on the screen every time we ran a poll while a VGA display was connected. Luckily, radeon_vga_detect() only resorts to this sort of polling if the poll is forced, and DRM's polling helper doesn't force it's polls. Additionally, this removes some assignments to connector->polled that weren't actually doing anything. Signed-off-by:
Lyude <cpaul@redhat.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Theodore Ts'o authored
commit 5b9554dc upstream. If s_reserved_gdt_blocks is extremely large, it's possible for ext4_init_block_bitmap(), which is called when ext4 sets up an uninitialized block bitmap, to corrupt random kernel memory. Add the same checks which e2fsck has --- it must never be larger than blocksize / sizeof(__u32) --- and then add a backup check in ext4_init_block_bitmap() in case the superblock gets modified after the file system is mounted. Reported-by:
Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.2: - Drop the second check in ext4_init_block_bitmap() since it can't return an error code - Adjust context] Signed-off-by:
-
Vegard Nossum authored
commit 6a7fd522 upstream. If ext4_fill_super() fails early, it's possible for ext4_evict_inode() to call ext4_should_journal_data() before superblock options and flags are fully set up. In that case, the iput() on the journal inode can end up causing a BUG(). Work around this problem by reordering the tests so we only call ext4_should_journal_data() after we know it's not the journal inode. Fixes: 2d859db3 ("ext4: fix data corruption in inodes with journalled data") Fixes: 2b405bfa ("ext4: fix data=journal fast mount/umount hang") Cc: Jan Kara <jack@suse.cz> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Vegard Nossum authored
commit f70749ca upstream. An extent with lblock = 4294967295 and len = 1 will pass the ext4_valid_extent() test: ext4_lblk_t last = lblock + len - 1; if (len == 0 || lblock > last) return 0; since last = 4294967295 + 1 - 1 = 4294967295. This would later trigger the BUG_ON(es->es_lblk + es->es_len < es->es_lblk) in ext4_es_end(). We can simplify it by removing the - 1 altogether and changing the test to use lblock + len <= lblock, since now if len = 0, then lblock + 0 == lblock and it fails, and if len > 0 then lblock + len > lblock in order to pass (i.e. it doesn't overflow). Fixes: 5946d089 ("ext4: check for overlapping extents in ext4_valid_extent_entries()") Fixes: 2f974865 ("ext4: check for zero length extent explicitly") Cc: Eryu Guan <guaneryu@gmail.com> Signed-off-by:
Phil Turnbull <phil.turnbull@oracle.com> Signed-off-by:
-
Cameron Gutman authored
commit caca925f upstream. This prevents a malicious USB device from causing an oops. Signed-off-by:
Cameron Gutman <aicommander@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Yoshihiro Shimoda authored
commit 15e4292a upstream. This patch fixes an issue that the CFIFOSEL register value is possible to be changed by usbhsg_ep_enable() wrongly. And then, a data transfer using CFIFO may not work correctly. For example: # modprobe g_multi file=usb-storage.bin # ifconfig usb0 192.168.1.1 up (During the USB host is sending file to the mass storage) # ifconfig usb0 down In this case, since the u_ether.c may call usb_ep_enable() in eth_stop(), if the renesas_usbhs driver is also using CFIFO for mass storage, the mass storage may not work correctly. So, this patch adds usbhs_lock() and usbhs_unlock() calling in usbhsg_ep_enable() to protect CFIFOSEL register. This is because: - CFIFOSEL.CURPIPE = 0 is also needed for the pipe configuration - The CFIFOSEL (fifo->sel) is already protected by usbhs_lock() Fixes: 97664a20 ("usb: renesas_usbhs: shrink spin lock area") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Yoshihiro Shimoda authored
commit 4fdef698 upstream. This patch fixes an issue that the xfer_work() is possible to cause NULL pointer dereference if the usb cable is disconnected while data transfer is running. In such case, a gadget driver may call usb_ep_disable()) before xfer_work() is actually called. In this case, the usbhs_pkt_pop() will call usbhsf_fifo_unselect(), and then usbhs_pipe_to_fifo() in xfer_work() will return NULL. Fixes: e73a9891 ("usb: renesas_usbhs: add DMAEngine support") Signed-off-by:
-
Krzysztof Kozlowski authored
commit 926b7b51 upstream. On non-DeviceTree platforms, the index of serial device is a static variable incremented on each probe. It is incremented even if deferred probe happens when getting the clock in s3c24xx_serial_init_port(). This index is used for referencing elements of statically allocated s3c24xx_serial_ports array. In case of re-probe, the index will point outside of this array leading to memory corruption. Increment the index only on successful probe. Reported-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Fixes: b497549a ("[ARM] S3C24XX: Split serial driver into core and per-cpu drivers") Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Herbert Xu authored
commit b30bdfa8 upstream. As it is if you ask for a sync gcm you may actually end up with an async one because it does not filter out async implementations of ghash. This patch fixes this by adding the necessary filter when looking for ghash. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Wanpeng Li authored
commit 3d89e547 upstream. Commit: e9532e69 ("sched/cputime: Fix steal time accounting vs. CPU hotplug") ... set rq->prev_* to 0 after a CPU hotplug comes back, in order to fix the case where (after CPU hotplug) steal time is smaller than rq->prev_steal_time. However, this should never happen. Steal time was only smaller because of the KVM-specific bug fixed by the previous patch. Worse, the previous patch triggers a bug on CPU hot-unplug/plug operation: because rq->prev_steal_time is cleared, all of the CPU's past steal time will be accounted again on hot-plug. Since the root cause has been fixed, we can just revert commit e9532e69. Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 'commit e9532e69 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")' Link: http://lkml.kernel.org/r/1465813966-3116-3-git-send-email-wanpeng.li@hotmail.comSigned-off-by:
-
Bharata B Rao authored
commit 45b64ee6 upstream. memory_hotplug_max() uses hot_add_drconf_memory_max() to get maxmimum addressable memory by referring to ibm,dyanamic-memory property. There are three problems with the current approach: 1 hot_add_drconf_memory_max() assumes that ibm,dynamic-memory includes all the LMBs of the guest, but that is not true for PowerKVM which populates only DR LMBs (LMBs that can be hotplugged/removed) in that property. 2 hot_add_drconf_memory_max() multiplies lmb-size with lmb-count to arrive at the max possible address. Since ibm,dynamic-memory doesn't include RMA LMBs, the address thus obtained will be less than the actual max address. For example, if max possible memory size is 32G, with lmb-size of 256MB there can be 127 LMBs in ibm,dynamic-memory (1 LMB for RMA which won't be present here). hot_add_drconf_memory_max() would then return the max addressable memory as 127 * 256MB = 31.75GB, the max address should have been 32G which is what ibm,lrdr-capacity shows. 3 In PowerKVM, there can be a gap between the end of boot time RAM and beginning of hotplug RAM area. So just multiplying lmb-count with lmb-size will not provide the correct max possible address for PowerKVM. This patch fixes 1 by using ibm,lrdr-capacity property to return the max addressable memory whenever the property is present. Then it fixes 2 & 3 by fetching the address of the last LMB in ibm,dynamic-memory property. Fixes: cd34206e ("powerpc: Add memory_hotplug_max()") Signed-off-by:
Bharata B Rao <bharata@linux.vnet.ibm.com> Reviewed-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Paul Moore authored
commit 0e0e3677 upstream. It seems risky to always rely on the caller to ensure the socket's address family is correct before passing it to the NetLabel kAPI, especially since we see at least one LSM which didn't. Add address family checks to the *_delattr() functions to help prevent future problems. Reported-by:
Maninder Singh <maninder1.s@samsung.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
- 20 Oct, 2016 2 commits
-
-
Ben Hutchings authored
-
Michal Hocko authored
commit 19be0eaf upstream. faultin_page drops FOLL_WRITE after the page fault handler did the CoW and then we retry follow_page_mask to get our CoWed page. This is racy, however because the page might have been unmapped by that time and so we would have to do a page fault again, this time without CoW. This would cause the page cache corruption for FOLL_FORCE on MAP_PRIVATE read only mappings with obvious consequences. This is an ancient bug that was actually already fixed once by Linus eleven years ago in commit 4ceb5db9 ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f4 ("fix get_user_pages bug") because s390 didn't have proper dirty pte tracking until abf09bed ("s390/mm: implement software dirty bits"). This wasn't a problem at the time as pointed out by Hugh Dickins because madvise relied on mmap_sem for write up until 0a27a14a ("mm: madvise avoid exclusive mmap_sem") but since then we can race with madvise which can unmap the fresh COWed page or with KSM and corrupt the content of the shared page. This patch is based on the Linus' approach to not clear FOLL_WRITE after the CoW page fault (aka VM_FAULT_WRITE) but instead introduces FOLL_COW to note this fact. The flag is then rechecked during follow_pfn_pte to enforce the page fault again if we do not see the CoWed page. Linus was suggesting to check pte_dirty again as s390 is OK now. But that would make backporting to some old kernels harder. So instead let's just make sure that vm_normal_page sees a pure anonymous page. This would guarantee we are seeing a real CoW page. Introduce can_follow_write_pte which checks both pte_write and falls back to PageAnon on forced write faults which passed CoW already. Thanks to Hugh to point out that a special care has to be taken for KSM pages because our COWed page might have been merged with a KSM one and keep its PageAnon flag. Fixes: 0a27a14a ("mm: madvise avoid exclusive mmap_sem") Reported-by:
Phil "not Paul" Oester <kernel@linuxace.com> Disclosed-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Michal Hocko <mhocko@suse.com> [bwh: Backported to 3.2: - Adjust filename, context, indentation - The 'no_page' exit path in follow_page() is different, so open-code the cleanup - Delete a now-unused label] Signed-off-by:
-
- 22 Aug, 2016 23 commits
-
-
Ben Hutchings authored
-
Paul Moore authored
commit 43761473 upstream. There is a double fetch problem in audit_log_single_execve_arg() where we first check the execve(2) argumnets for any "bad" characters which would require hex encoding and then re-fetch the arguments for logging in the audit record[1]. Of course this leaves a window of opportunity for an unsavory application to munge with the data. This patch reworks things by only fetching the argument data once[2] into a buffer where it is scanned and logged into the audit records(s). In addition to fixing the double fetch, this patch improves on the original code in a few other ways: better handling of large arguments which require encoding, stricter record length checking, and some performance improvements (completely unverified, but we got rid of some strlen() calls, that's got to be a good thing). As part of the development of this patch, I've also created a basic regression test for the audit-testsuite, the test can be tracked on GitHub at the following link: * https://github.com/linux-audit/audit-testsuite/issues/25 [1] If you pay careful attention, there is actually a triple fetch problem due to a strnlen_user() call at the top of the function. [2] This is a tiny white lie, we do make a call to strnlen_user() prior to fetching the argument data. I don't like it, but due to the way the audit record is structured we really have no choice unless we copy the entire argument at once (which would require a rather wasteful allocation). The good news is that with this patch the kernel no longer relies on this strnlen_user() value for anything beyond recording it in the log, we also update it with a trustworthy value whenever possible. Reported-by:
Pengfei Wang <wpengfeinudt@gmail.com> Signed-off-by:
-
Eric Dumazet authored
commit 75ff39cc upstream. Yue Cao claims that current host rate limiting of challenge ACKS (RFC 5961) could leak enough information to allow a patient attacker to hijack TCP sessions. He will soon provide details in an academic paper. This patch increases the default limit from 100 to 1000, and adds some randomization so that the attacker can no longer hijack sessions without spending a considerable amount of probes. Based on initial analysis and patch from Linus. Note that we also have per socket rate limiting, so it is tempting to remove the host limit in the future. v2: randomize the count of challenge acks per second, not the period. Fixes: 282f23c6 ("tcp: implement RFC 5961 3.2") Reported-by:
Yue Cao <ycao009@ucr.edu> Signed-off-by:
Eric Dumazet <edumazet@google.com> Suggested-by:
Neal Cardwell <ncardwell@google.com> Acked-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
Kangjie Lu authored
commit 4116def2 upstream. The last field "flags" of object "minfo" is not initialized. Copying this object out may leak kernel stack data. Assign 0 to it to avoid leak. Signed-off-by:
Kangjie Lu <kjlu@gatech.edu> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Kangjie Lu authored
commit 5d2be142 upstream. link_info.str is a char array of size 60. Memory after the NULL byte is not initialized. Sending the whole object out can cause a leak. Signed-off-by:
-
Kangjie Lu authored
commit e4ec8cc8 upstream. The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by:
-
Kangjie Lu authored
commit 9a47e9cf upstream. The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by:
-
Kangjie Lu authored
commit cec8f96e upstream. The stack object “tread” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by:
-
Kangjie Lu authored
commit 681fef83 upstream. The stack object “ci” has a total size of 8 bytes. Its last 3 bytes are padding bytes which are not initialized and leaked to userland via “copy_to_user”. Signed-off-by:
-
Jann Horn authored
commit e54ad7f1 upstream. This prevents stacking filesystems (ecryptfs and overlayfs) from using procfs as lower filesystem. There is too much magic going on inside procfs, and there is no good reason to stack stuff on top of procfs. (For example, procfs does access checks in VFS open handlers, and ecryptfs by design calls open handlers from a kernel thread that doesn't drop privileges or so.) Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
-
Miklos Szeredi authored
commit 69c433ed upstream. Add a simple read-only counter to super_block that indicates how deep this is in the stack of filesystems. Previously ecryptfs was the only stackable filesystem and it explicitly disallowed multiple layers of itself. Overlayfs, however, can be stacked recursively and also may be stacked on top of ecryptfs or vice versa. To limit the kernel stack usage we must limit the depth of the filesystem stack. Initially the limit is set to 2. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> [bwh: Backported to 3.2: - Drop changes to overlayfs - Adjust context] Signed-off-by:
-
Jerome Marchand authored
commit b8da344b upstream. In sess_auth_rawntlmssp_authenticate(), the ntlmssp blob is allocated statically and its size is an "empirical" 5*sizeof(struct _AUTHENTICATE_MESSAGE) (320B on x86_64). I don't know where this value comes from or if it was ever appropriate, but it is currently insufficient: the user and domain name in UTF16 could take 1kB by themselves. Because of that, build_ntlmssp_auth_blob() might corrupt memory (out-of-bounds write). The size of ntlmssp_blob in SMB2_sess_setup() is too small too (sizeof(struct _NEGOTIATE_MESSAGE) + 500). This patch allocates the blob dynamically in build_ntlmssp_auth_blob(). Signed-off-by:
Jerome Marchand <jmarchan@redhat.com> Signed-off-by:
Steve French <smfrench@gmail.com> [bwh: Backported to 3.2: - Adjust context, indentation - build_ntlmssp_auth_blob() is static - Drop changes to smb2pdu.c - Use cERROR() instead of cifs_dbg(VFS, ...) - Use MAX_USERNAME_SIZE instead of CIFS_MAX_USERNAME_LEN] Signed-off-by:
-
Jeff Mahoney authored
commit f0fe970d upstream. There are legitimate reasons to disallow mmap on certain files, notably in sysfs or procfs. We shouldn't emulate mmap support on file systems that don't offer support natively. CVE-2016-1583 Signed-off-by:
Jeff Mahoney <jeffm@suse.com> [tyhicks: clean up f_op check by using ecryptfs_file_to_lower()] Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
-
Ursula Braun authored
commit 7831b4ff upstream. A qeth_card contains a napi_struct linked to the net_device during device probing. This struct must be deleted when removing the qeth device, otherwise Panic on oops can occur when qeth devices are repeatedly removed and added. Fixes: a1c3ed4c ("qeth: NAPI support for l2 and l3 discipline") Signed-off-by:
Ursula Braun <ubraun@linux.vnet.ibm.com> Tested-by:
Alexander Klein <ALKL@de.ibm.com> Signed-off-by:
-
Takashi Iwai authored
commit 3fa6993f upstream. The user timer tu->qused counter may go to a negative value when multiple concurrent reads are performed since both the check and the decrement of tu->qused are done in two individual locked contexts. This results in bogus read outs, and the endless loop in the user-space side. The fix is to move the decrement of the tu->qused counter into the same spinlock context as the zero-check of the counter. Signed-off-by:
-
Eric Dumazet authored
commit f87fda00 upstream. ether_addr_equal_64bits() requires some care about its arguments, namely that 8 bytes might be read, even if last 2 byte values are not used. KASan detected a violation with null_mac_addr and lacpdu_mcast_addr in bond_3ad.c Same problem with mac_bcast[] and mac_v6_allmcast[] in bond_alb.c : Although the 8-byte alignment was there, KASan would detect out of bound accesses. Fixes: 815117ad ("bonding: use ether_addr_equal_unaligned for bond addr compare") Fixes: bb54e589 ("bonding: Verify RX LACPDU has proper dest mac-addr") Fixes: 885a136c ("bonding: use compare_ether_addr_64bits() in ALB") Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Acked-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by:
Ding Tianhong <dingtianhong@huawei.com> Signed-off-by:
-
Duan Jiong authored
commit 6d57e907 upstream. a lot of code has either the memset or an inefficient copy from a static array that contains the all-zeros Ethernet address. Introduce help function eth_zero_addr() to fill an address with all zeros, making the code clearer and allowing us to get rid of some constant arrays. Signed-off-by:
Duan Jiong <djduanjiong@gmail.com> Signed-off-by:
-
Borislav Petkov authored
commit 1ead852d upstream. Fix boot crash that triggers if this driver is built into a kernel and run on non-AMD systems. AMD northbridges users call amd_cache_northbridges() and it returns a negative value to signal that we weren't able to cache/detect any northbridges on the system. At least, it should do so as all its callers expect it to do so. But it does return a negative value only when kmalloc() fails. Fix it to return -ENODEV if there are no NBs cached as otherwise, amd_nb users like amd64_edac, for example, which relies on it to know whether it should load or not, gets loaded on systems like Intel Xeons where it shouldn't. Reported-and-tested-by:
Tony Battersby <tonyb@cybernetics.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1466097230-5333-2-git-send-email-bp@alien8.de Link: https://lkml.kernel.org/r/5761BEB0.9000807@cybernetics.comSigned-off-by:
-
Takashi Iwai authored
commit 62db7152 upstream. vortex_wtdma_bufshift() function does calculate the page index wrongly, first masking then shift, which always results in zero. The proper computation is to first shift, then mask. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Sven Eckelmann authored
commit 9c4604a2 upstream. The tt_req_node is added and removed from a list inside a spinlock. But the locking is sometimes removed even when the object is still referenced and will be used later via this reference. For example batadv_send_tt_request can create a new tt_req_node (including add to a list) and later re-acquires the lock to remove it from the list and to free it. But at this time another context could have already removed this tt_req_node from the list and freed it. CPU#0 batadv_batman_skb_recv from net_device 0 -> batadv_iv_ogm_receive -> batadv_iv_ogm_process -> batadv_iv_ogm_process_per_outif -> batadv_tvlv_ogm_receive -> batadv_tvlv_ogm_receive -> batadv_tvlv_containers_process -> batadv_tvlv_call_handler -> batadv_tt_tvlv_ogm_handler_v1 -> batadv_tt_update_orig -> batadv_send_tt_request -> batadv_tt_req_node_new spin_lock(...) allocates new tt_req_node and adds it to list spin_unlock(...) return tt_req_node CPU#1 batadv_batman_skb_recv from net_device 1 -> batadv_recv_unicast_tvlv -> batadv_tvlv_containers_process -> batadv_tvlv_call_handler -> batadv_tt_tvlv_unicast_handler_v1 -> batadv_handle_tt_response spin_lock(...) tt_req_node gets removed from list and is freed spin_unlock(...) CPU#0 <- returned to batadv_send_tt_request spin_lock(...) tt_req_node gets removed from list and is freed MEMORY CORRUPTION/SEGFAULT/... spin_unlock(...) This can only be solved via reference counting to allow multiple contexts to handle the list manipulation while making sure that only the last context holding a reference will free the object. Fixes: a73105b8 ("batman-adv: improved client announcement mechanism") Signed-off-by:
Sven Eckelmann <sven@narfation.org> Tested-by:
Martin Weinelt <martin@darmstadt.freifunk.net> Tested-by:
Amadeus Alfa <amadeus@chemnitz.freifunk.net> Signed-off-by:
Marek Lindner <mareklindner@neomailbox.ch> Signed-off-by:
-
Trond Myklebust authored
commit e547f262 upstream. Olga Kornievskaia reports that the following test fails to trigger an OPEN_DOWNGRADE on the wire, and only triggers the final CLOSE. fd0 = open(foo, RDRW) -- should be open on the wire for "both" fd1 = open(foo, RDONLY) -- should be open on the wire for "read" close(fd0) -- should trigger an open_downgrade read(fd1) close(fd1) The issue is that we're missing a check for whether or not the current state transitioned from an O_RDWR state as opposed to having transitioned from a combination of O_RDONLY and O_WRONLY. Reported-by:
Olga Kornievskaia <aglo@umich.edu> Fixes: cd9288ff ("NFSv4: Fix another bug in the close/open_downgrade code") Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Christophe JAILLET authored
commit 9c6795a9 upstream. 'commpage_bak' is allocated with 'sizeof(struct echoaudio)' bytes. We then copy 'sizeof(struct comm_page)' bytes in it. On my system, smatch complains because one is 2960 and the other is 3072. This would result in memory corruption or a oops. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Linus Walleij authored
commit 0c1f91b9 upstream. These two spi_w8r8() calls return a value with is used by the code following the error check. The dubious use was caused by a cleanup patch. Fixes: d34dbee8 ("staging:iio:accel:kxsd9 cleanup and conversion to iio_chan_spec.") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> [bwh: Backported to 3.2: adjust filename] Signed-off-by:
-
