- 23 Nov, 2018 18 commits
-
-
Arnd Bergmann authored
commit 1f318a8b upstream. clang warns about unused inline functions by default: arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' [-Wunused-function] arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' [-Wunused-function] As these appear in every single module, let's just disable the warnings by marking the two functions as __maybe_unused. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Miroslav Benes <mbenes@suse.cz> Acked-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Jessica Yu <jeyu@redhat.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vinícius Tinti authored
commit 433db3e2 upstream. Add rules to kbuild in order to generate LLVM assembly files with the .ll extension when using clang. # from c code make CC=clang kernel/pid.ll Signed-off-by:
Vinícius Tinti <viniciustinti@gmail.com> Signed-off-by:
Behan Webster <behanw@converseincode.com> Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Behan Webster authored
commit 6748cb3c upstream. This generates smaller resulting object code when compiled with clang. Signed-off-by:
-
Mark Charlebois authored
commit c3f0d0bc upstream. Clang will warn about unknown warnings but will not return false unless -Werror is set. GCC will return false if an unknown warning is passed. Adding -Werror make both compiler behave the same. [arnd: it turns out we need the same patch for testing whether -ffunction-sections works right with gcc. I've build tested extensively with this patch applied, so let's just merge this one now.] Signed-off-by:
Mark Charlebois <charlebm@gmail.com> Signed-off-by:
Jan-Simon Möller <dl9pf@gmx.de> Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Masahiro Yamada authored
commit a0ae981e upstream. Since commit c3f0d0bc ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"), cc-option and friends work nicely for clang. However, -Wno-unknown-warning-option makes clang happy with any unknown warning options even if -Werror is specified. Once -Wno-unknown-warning-option is added, any succeeding call of cc-disable-warning is evaluated positive, then unknown warning options are accepted. This should be dropped. Signed-off-by:
-
Jeroen Hofstee authored
commit cf0c3e68 upstream. KBuild abuses the asm statement to write to a file and clang chokes about these invalid asm statements. Hack it even more by fooling this is actual valid asm code. [masahiro: Import Jeroen's work for U-Boot: http://patchwork.ozlabs.org/patch/375026/ Tweak sed script a little to avoid garbage '#' for GCC case, like #define NR_PAGEFLAGS 23 /* __NR_PAGEFLAGS # */ ] Signed-off-by:
Jeroen Hofstee <jeroen@myspectrum.nl> Signed-off-by:
-
Masahiro Yamada authored
commit 7dd47b95 upstream. This part ended up in redundant code after touched by multiple people. [1] Commit 3234282f ("x86, asm: Fix CFI macro invocations to deal with shortcomings in gas") added parentheses for defined expressions to support old gas for x86. [2] Commit a22dcdb0 ("x86, asm: Fix ancient-GAS workaround") split the pattern into two to avoid parentheses for non-numeric expressions. [3] Commit 95a2f6f7 ("Partially revert patch that encloses asm-offset.h numbers in brackets") removed parentheses from numeric expressions as well because parentheses in MN10300 assembly have a special meaning (pointer access). Apparently, there is a conflict between [1] and [3]. After all, [3] took precedence, and a long time has passed since then. Now, merge the two patterns again because the first one is covered by the other. Signed-off-by:
-
Matthias Kaehlcke authored
commit ebf003f0 upstream. Largely redundant code is used in different places to generate C headers from offset information extracted from assembly language output. Consolidate the code in Makefile.lib and use this instead. Signed-off-by:
-
Michael Davidson authored
commit a37c45cd upstream. The Linux Kernel relies on GCC's acceptance of inline assembly as an opaque object which will not have any validation performed on the content. The current behaviour in LLVM is to perform validation of the contents by means of parsing the input if the MC layer can handle it. Disable clangs integrated assembler and use the GNU assembler instead. Wording-mostly-from: Saleem Abdulrasool <compnerd@compnerd.org> Signed-off-by:
Michael Davidson <md@google.com> Signed-off-by:
-
Behan Webster authored
commit 785f11aa upstream. Add cross target to CC if using clang. Also add custom gcc toolchain path for fallback gcc tools. Clang will fallback to using things like ld, as, and libgcc if (respectively) one of the llvm linkers isn't available, the integrated assembler is turned off, or an appropriately cross-compiled version of compiler-rt isn't available. To this end, you can specify the path to this fallback gcc toolchain with GCC_TOOLCHAIN. Signed-off-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
-
David Ahern authored
[ Upstream commit 7ddacfa5 ] Preethi reported that PMTU discovery for UDP/raw applications is not working in the presence of VRF when the socket is not bound to a device. The problem is that ip6_sk_update_pmtu does not consider the L3 domain of the skb device if the socket is not bound. Update the function to set oif to the L3 master device if relevant. Fixes: ca254490 ("net: Add VRF support to IPv6 stack") Reported-by:
Preethi Ramachandra <preethir@juniper.net> Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 0d5b9311 ] Multiple cpus might attempt to insert a new fragment in rhashtable, if for example RPS is buggy, as reported by 배석진 in https://patchwork.ozlabs.org/patch/994601/ We use rhashtable_lookup_get_insert_key() instead of rhashtable_insert_fast() to let cpus losing the race free their own inet_frag_queue and use the one that was inserted by another cpu. Fixes: 648700f7 ("inet: frags: use rhashtables for reassembly units") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
배석진 <soukjin.bae@samsung.com> Signed-off-by:
-
Frieder Schrempf authored
[ Upstream commit 7b900ead ] We need to make sure, that the carrier check polling is disabled while suspending. Otherwise we can end up with usbnet_read_cmd() being issued when only usbnet_read_cmd_nopm() is allowed. If this happens, read operations lock up. Fixes: d69d1694 ("usbnet: smsc95xx: fix link detection for disabled autonegotiation") Signed-off-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by:
Raghuram Chary J <RaghuramChary.Jallipalli@microchip.com> Signed-off-by:
-
Siva Reddy Kallam authored
[ Upstream commit 59663e42 ] This patch has the fix to avoid PHY lockup with 5717/5719/5720 in change ring and flow control paths. This patch solves the RX hang while doing continuous ring or flow control parameters with heavy traffic from peer. Signed-off-by:
Siva Reddy Kallam <siva.kallam@broadcom.com> Acked-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Xin Long authored
[ Upstream commit cc3ccf26 ] As rfc7496#section4.5 says about SCTP_PR_SUPPORTED: This socket option allows the enabling or disabling of the negotiation of PR-SCTP support for future associations. For existing associations, it allows one to query whether or not PR-SCTP support was negotiated on a particular association. It means only sctp sock's prsctp_enable can be set. Note that for the limitation of SCTP_{CURRENT|ALL}_ASSOC, we will add it when introducing SCTP_{FUTURE|CURRENT|ALL}_ASSOC for linux sctp in another patchset. v1->v2: - drop the params.assoc_id check as Neil suggested. Fixes: 28aa4c26 ("sctp: add SCTP_PR_SUPPORTED on sctp sockopt") Reported-by:
Ying Xu <yinxu@redhat.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 33d9a2c7 ] eth_type_trans() assumes initial value for skb->pkt_type is PACKET_HOST. This is indeed the value right after a fresh skb allocation. However, it is possible that GRO merged a packet with a different value (like PACKET_OTHERHOST in case macvlan is used), so we need to make sure napi->skb will have pkt_type set back to PACKET_HOST. Otherwise, valid packets might be dropped by the stack because their pkt_type is not PACKET_HOST. napi_reuse_skb() was added in commit 96e93eab ("gro: Add internal interfaces for VLAN"), but this bug always has been there. Fixes: 96e93eab ("gro: Add internal interfaces for VLAN") Signed-off-by:
-
Sabrina Dubroca authored
[ Upstream commit 16f7eb2b ] The various types of tunnels running over IPv4 can ask to set the DF bit to do PMTU discovery. However, PMTU discovery is subject to the threshold set by the net.ipv4.route.min_pmtu sysctl, and is also disabled on routes with "mtu lock". In those cases, we shouldn't set the DF bit. This patch makes setting the DF bit conditional on the route's MTU locking state. This issue seems to be older than git history. Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Reviewed-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
-
배석진 authored
[ Upstream commit 62230715 ] Only first fragment has the sport/dport information, not the following ones. If we want consistent hash for all fragments, we need to ignore ports even for first fragment. This bug is visible for IPv6 traffic, if incoming fragments do not have a flow label, since skb_get_hash() will give different results for first fragment and following ones. It is also visible if any routing rule wants dissection and sport or dport. See commit 5e5d6fed ("ipv6: route: dissect flow in input path if fib rules need it") for details. [edumazet] rewrote the changelog completely. Fixes: 06635a35 ("flow_dissect: use programable dissector in skb_flow_dissect and friends") Signed-off-by:
-
- 21 Nov, 2018 22 commits
-
-
Greg Kroah-Hartman authored
-
Mark Rutland authored
commit da5a3ce6 upstream. At boot time, KVM stashes the host MDCR_EL2 value, but only does this when the kernel is not running in hyp mode (i.e. is non-VHE). In these cases, the stashed value of MDCR_EL2.HPMN happens to be zero, which can lead to CONSTRAINED UNPREDICTABLE behaviour. Since we use this value to derive the MDCR_EL2 value when switching to/from a guest, after a guest have been run, the performance counters do not behave as expected. This has been observed to result in accesses via PMXEVTYPER_EL0 and PMXEVCNTR_EL0 not affecting the relevant counters, resulting in events not being counted. In these cases, only the fixed-purpose cycle counter appears to work as expected. Fix this by always stashing the host MDCR_EL2 value, regardless of VHE. Cc: Christopher Dall <christoffer.dall@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: stable@vger.kernel.org Fixes: 1e947bad ("arm64: KVM: Skip HYP setup when already running in HYP") Tested-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Chris Wilson authored
commit 0a823e8f upstream. Ensure that the writes into the context image are completed prior to the register mmio to trigger execution. Although previously we were assured by the SDM that all writes are flushed before an uncached memory transaction (our mmio write to submit the context to HW for execution), we have empirical evidence to believe that this is not actually the case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656 References: https://bugs.freedesktop.org/show_bug.cgi?id=108315 References: https://bugs.freedesktop.org/show_bug.cgi?id=106887Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108081740.25615-1-chris@chris-wilson.co.uk Cc: stable@vger.kernel.org (cherry picked from commit 987abd5c) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Clint Taylor authored
commit 65034931 upstream. HDMI 2.0 594Mhz modes were incorrectly selecting 25.200Mhz Automatic N value mode instead of HDMI specification values. V2: Fix 88.2 Hz N value Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1540493521-1746-2-git-send-email-clinton.a.taylor@intel.com (cherry picked from commit 5a400aa3) Signed-off-by:
-
Stanislav Lisovskiy authored
commit 23d80039 upstream. Unfortunately drm_dp_get_mst_branch_device which is called from both drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely on that mgr->mst_primary is not NULL, which seem to be wrong as it can be cleared with simultaneous mode set, if probing fails or in other case. mgr->lock mutex doesn't protect against that as it might just get assigned to NULL right before, not simultaneously. There are currently bugs 107738, 108616 bugs which crash in drm_dp_get_mst_branch_device, caused by this issue. v2: Refactored the code, as it was nicely noticed. Fixed Bugzilla bug numbers(second was 108616, but not 108816) and added links. [changed title and added stable cc] Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108616 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107738 Link: https://patchwork.freedesktop.org/patch/msgid/20181109090012.24438-1-stanislav.lisovskiy@intel.comSigned-off-by:
-
Marc Zyngier authored
commit 7f3ef5de upstream. Leaving the DRM driver enabled on reboot or kexec has the annoying effect of leaving the display generating transactions whilst the IOMMU has been shut down. In turn, the IOMMU driver (which shares its interrupt line with the VOP) starts warning either on shutdown or when entering the secondary kernel in the kexec case (nothing is expected on that front). A cheap way of ensuring that things are nicely shut down is to register a shutdown callback in the platform driver. Signed-off-by:
Vicente Bergas <vicencb@gmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180805124807.18169-1-marc.zyngier@arm.com Cc: stable@vger.kernel.org Signed-off-by:
-
Mike Kravetz authored
commit 017b1660 upstream. The page migration code employs try_to_unmap() to try and unmap the source page. This is accomplished by using rmap_walk to find all vmas where the page is mapped. This search stops when page mapcount is zero. For shared PMD huge pages, the page map count is always 1 no matter the number of mappings. Shared mappings are tracked via the reference count of the PMD page. Therefore, try_to_unmap stops prematurely and does not completely unmap all mappings of the source page. This problem can result is data corruption as writes to the original source page can happen after contents of the page are copied to the target page. Hence, data is lost. This problem was originally seen as DB corruption of shared global areas after a huge page was soft offlined due to ECC memory errors. DB developers noticed they could reproduce the issue by (hotplug) offlining memory used to back huge pages. A simple testcase can reproduce the problem by creating a shared PMD mapping (note that this must be at least PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using migrate_pages() to migrate process pages between nodes while continually writing to the huge pages being migrated. To fix, have the try_to_unmap_one routine check for huge PMD sharing by calling huge_pmd_unshare for hugetlbfs huge pages. If it is a shared mapping it will be 'unshared' which removes the page table entry and drops the reference on the PMD page. After this, flush caches and TLB. mmu notifiers are called before locking page tables, but we can not be sure of PMD sharing until page tables are locked. Therefore, check for the possibility of PMD sharing before locking so that notifiers can prepare for the worst possible case. Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.kravetz@oracle.com [mike.kravetz@oracle.com: make _range_in_vma() a static inline] Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc952d@oracle.com Fixes: 39dde65c ("shared page table for hugetlb page") Signed-off-by:
Mike Kravetz <mike.kravetz@oracle.com> Acked-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jérôme Glisse <jglisse@redhat.com> Acked-by:
-
Mike Kravetz authored
commit 5e41540c upstream. This bug has been experienced several times by the Oracle DB team. The BUG is in remove_inode_hugepages() as follows: /* * If page is mapped, it was faulted in after being * unmapped in caller. Unmap (again) now after taking * the fault mutex. The mutex will prevent faults * until we finish removing the page. * * This race can only happen in the hole punch case. * Getting here in a truncate operation is a bug. */ if (unlikely(page_mapped(page))) { BUG_ON(truncate_op); In this case, the elevated map count is not the result of a race. Rather it was incorrectly incremented as the result of a bug in the huge pmd sharing code. Consider the following: - Process A maps a hugetlbfs file of sufficient size and alignment (PUD_SIZE) that a pmd page could be shared. - Process B maps the same hugetlbfs file with the same size and alignment such that a pmd page is shared. - Process B then calls mprotect() to change protections for the mapping with the shared pmd. As a result, the pmd is 'unshared'. - Process B then calls mprotect() again to chage protections for the mapping back to their original value. pmd remains unshared. - Process B then forks and process C is created. During the fork process, we do dup_mm -> dup_mmap -> copy_page_range to copy page tables. Copying page tables for hugetlb mappings is done in the routine copy_hugetlb_page_range. In copy_hugetlb_page_range(), the destination pte is obtained by: dst_pte = huge_pte_alloc(dst, addr, sz); If pmd sharing is possible, the returned pointer will be to a pte in an existing page table. In the situation above, process C could share with either process A or process B. Since process A is first in the list, the returned pte is a pointer to a pte in process A's page table. However, the check for pmd sharing in copy_hugetlb_page_range is: /* If the pagetables are shared don't copy or take references */ if (dst_pte == src_pte) continue; Since process C is sharing with process A instead of process B, the above test fails. The code in copy_hugetlb_page_range which follows assumes dst_pte points to a huge_pte_none pte. It copies the pte entry from src_pte to dst_pte and increments this map count of the associated page. This is how we end up with an elevated map count. To solve, check the dst_pte entry for huge_pte_none. If !none, this implies PMD sharing so do not copy. Link: http://lkml.kernel.org/r/20181105212315.14125-1-mike.kravetz@oracle.com Fixes: c5c99429 ("fix hugepages leak due to pagetable page sharing") Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Arnd Bergmann authored
commit 1c23b410 upstream. gcc-8 complains about the prototype for this function: lib/ubsan.c:432:1: error: ignoring attribute 'noreturn' in declaration of a built-in function '__ubsan_handle_builtin_unreachable' because it conflicts with attribute 'const' [-Werror=attributes] This is actually a GCC's bug. In GCC internals __ubsan_handle_builtin_unreachable() declared with both 'noreturn' and 'const' attributes instead of only 'noreturn': https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84210 Workaround this by removing the noreturn attribute. [aryabinin: add information about GCC bug in changelog] Link: http://lkml.kernel.org/r/20181107144516.4587-1-aryabinin@virtuozzo.comSigned-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Acked-by:
Olof Johansson <olof@lixom.net> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Guenter Roeck authored
commit 1823342a upstream. gcc 8.1.0 complains: fs/configfs/symlink.c:67:3: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length fs/configfs/symlink.c: In function 'configfs_get_link': fs/configfs/symlink.c:63:13: note: length computed here Using strncpy() is indeed less than perfect since the length of data to be copied has already been determined with strlen(). Replace strncpy() with memcpy() to address the warning and optimize the code a little. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Nobuhiro Iwamatsu <nobuhiro.iwamatsu@cybertrust.co.jp> Signed-off-by:
-
Miklos Szeredi authored
commit 7fabaf30 upstream. fuse_request_send_notify_reply() may fail if the connection was reset for some reason (e.g. fs was unmounted). Don't leak request reference in this case. Besides leaking memory, this resulted in fc->num_waiting not being decremented and hence fuse_wait_aborted() left in a hanging and unkillable state. Fixes: 2d45ba38 ("fuse: add retrieve request") Fixes: b8f95e5d ("fuse: umount should wait for all requests") Reported-and-tested-by: syzbot+6339eda9cb4ebbc4c37b@syzkaller.appspotmail.com Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Cc: <stable@vger.kernel.org> #v2.6.36 Signed-off-by:
-
Lukas Czerner authored
commit ebacb812 upstream. In async IO blocking case the additional reference to the io is taken for it to survive fuse_aio_complete(). In non blocking case this additional reference is not needed, however we still reference io to figure out whether to wait for completion or not. This is wrong and will lead to use-after-free. Fix it by storing blocking information in separate variable. This was spotted by KASAN when running generic/208 fstest. Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Reported-by:
Zorro Lang <zlang@redhat.com> Signed-off-by:
-
Maciej W. Rozycki authored
commit 7ce9a992 upstream. Fix an issue with the 32-bit range error path in `rtc_hctosys' where no error code is set and consequently the successful preceding call result from `rtc_read_time' is propagated to `rtc_hctosys_ret'. This in turn makes any subsequent call to `hctosys_show' incorrectly report in sysfs that the system time has been set from this RTC while it has not. Set the error to ERANGE then if we can't express the result due to an overflow. Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Fixes: b3a5ac42 ("rtc: hctosys: Ensure system time doesn't overflow time_t") Cc: stable@vger.kernel.org # 4.17+ Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Scott Mayhew authored
commit 01310bb7 upstream. Make sure we have a saved filehandle, otherwise we'll oops with a null pointer dereference in nfs4_preprocess_stateid_op(). Signed-off-by:
Scott Mayhew <smayhew@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Frank Sorenson authored
commit 5d7a5bcb upstream. When truncating the encode buffer, the page_ptr is getting advanced, causing the next page to be skipped while encoding. The page is still included in the response, so the response contains a page of bogus data. We need to adjust the page_ptr backwards to ensure we encode the next page into the correct place. We saw this triggered when concurrent directory modifications caused nfsd4_encode_direct_fattr() to return nfserr_noent, and the resulting call to xdr_truncate_encode() corrupted the READDIR reply. Signed-off-by:
Frank Sorenson <sorenson@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Eric W. Biederman authored
commit 9c8e0a1b upstream. Timothy Baldwin <timbaldwin@fastmail.co.uk> wrote: > As per mount_namespaces(7) unprivileged users should not be able to look under mount points: > > Mounts that come as a single unit from more privileged mount are locked > together and may not be separated in a less privileged mount namespace. > > However they can: > > 1. Create a mount namespace. > 2. In the mount namespace open a file descriptor to the parent of a mount point. > 3. Destroy the mount namespace. > 4. Use the file descriptor to look under the mount point. > > I have reproduced this with Linux 4.16.18 and Linux 4.18-rc8. > > The setup: > > $ sudo sysctl kernel.unprivileged_userns_clone=1 > kernel.unprivileged_userns_clone = 1 > $ mkdir -p A/B/Secret > $ sudo mount -t tmpfs hide A/B > > > "Secret" is indeed hidden as expected: > > $ ls -lR A > A: > total 0 > drwxrwxrwt 2 root root 40 Feb 12 21:08 B > > A/B: > total 0 > > > The attack revealing "Secret": > > $ unshare -Umr sh -c "exec unshare -m ls -lR /proc/self/fd/4/ 4<A" > /proc/self/fd/4/: > total 0 > drwxr-xr-x 3 root root 60 Feb 12 21:08 B > > /proc/self/fd/4/B: > total 0 > drwxr-xr-x 2 root root 40 Feb 12 21:08 Secret > > /proc/self/fd/4/B/Secret: > total 0 I tracked this down to put_mnt_ns running passing UMOUNT_SYNC and disconnecting all of the mounts in a mount namespace. Fix this by factoring drop_mounts out of drop_collected_mounts and passing 0 instead of UMOUNT_SYNC. There are two possible behavior differences that result from this. - No longer setting UMOUNT_SYNC will no longer set MNT_SYNC_UMOUNT on the vfsmounts being unmounted. This effects the lazy rcu walk by kicking the walk out of rcu mode and forcing it to be a non-lazy walk. - No longer disconnecting locked mounts will keep some mounts around longer as they stay because the are locked to other mounts. There are only two users of drop_collected mounts: audit_tree.c and put_mnt_ns. In audit_tree.c the mounts are private and there are no rcu lazy walks only calls to iterate_mounts. So the changes should have no effect except for a small timing effect as the connected mounts are disconnected. In put_mnt_ns there may be references from process outside the mount namespace to the mounts. So the mounts remaining connected will be the bug fix that is needed. That rcu walks are allowed to continue appears not to be a problem especially as the rcu walk change was about an implementation detail not about semantics. Cc: stable@vger.kernel.org Fixes: 5ff9d8a6 ("vfs: Lock in place mounts from more privileged users") Reported-by:
Timothy Baldwin <timbaldwin@fastmail.co.uk> Tested-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
commit df7342b2 upstream. Jonathan Calmels from NVIDIA reported that he's able to bypass the mount visibility security check in place in the Linux kernel by using a combination of the unbindable property along with the private mount propagation option to allow a unprivileged user to see a path which was purposefully hidden by the root user. Reproducer: # Hide a path to all users using a tmpfs root@castiana:~# mount -t tmpfs tmpfs /sys/devices/ root@castiana:~# # As an unprivileged user, unshare user namespace and mount namespace stgraber@castiana:~$ unshare -U -m -r # Confirm the path is still not accessible root@castiana:~# ls /sys/devices/ # Make /sys recursively unbindable and private root@castiana:~# mount --make-runbindable /sys root@castiana:~# mount --make-private /sys # Recursively bind-mount the rest of /sys over to /mnnt root@castiana:~# mount --rbind /sys/ /mnt # Access our hidden /sys/device as an unprivileged user root@castiana:~# ls /mnt/devices/ breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual Solve this by teaching copy_tree to fail if a mount turns out to be both unbindable and locked. Cc: stable@vger.kernel.org Fixes: 5ff9d8a6 ("vfs: Lock in place mounts from more privileged users") Reported-by:
Jonathan Calmels <jcalmels@nvidia.com> Signed-off-by:
-
Eric W. Biederman authored
commit 25d202ed upstream. It was recently pointed out that the one instance of testing MNT_LOCKED outside of the namespace_sem is in ksys_umount. Fix that by adding a test inside of do_umount with namespace_sem and the mount_lock held. As it helps to fail fails the existing test is maintained with an additional comment pointing out that it may be racy because the locks are not held. Cc: stable@vger.kernel.org Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Fixes: 5ff9d8a6 ("vfs: Lock in place mounts from more privileged users") Signed-off-by:
-
Vasily Averin authored
commit de59fae0 upstream. Fixes: dc6982ff ("ext4: refactor code to read directory blocks ...") Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org # 3.9 Signed-off-by:
-
Vasily Averin authored
commit 6bdc9977 upstream. Fixes: 3f2571c1 ("ext4: factor out xattr moving") Fixes: 6dd4ee7c ("ext4: Expand extra_inodes space per ...") Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Vasily Averin authored
commit 45ae932d upstream. bs.bh was taken in previous ext4_xattr_block_find() call, it should be released before re-using Fixes: 7e01c8e5 ("ext3/4: fix uninitialized bs in ...") Signed-off-by:
-
Vasily Averin authored
commit af18e35b upstream. Fixes: c8585c6f ("ext4: fix races between changing inode journal ...") Signed-off-by:
-
