This repository has been archived by the owner on May 1, 2020. It is now read-only.
Lineage 16.0 #26
Closed
Lineage 16.0 #26
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… issue page allocated in fuse_dentry_canonical_path to be handled in fuse_dev_do_write is allocated using __get_free_pages(GFP_KERNEL). This may not return a page with data filled with 0. Now this page may not have a null terminator at all. If this happens and userspace fuse daemon screws up by passing a string to kernel which is not NULL terminated (or did not fill anything), then inside fuse driver in kernel when we try to do strlen(fuse_dev_write->kern_path->getname_kernel) on that page data -> it may give us issue with kernel paging request. Unable to handle kernel paging request at virtual address ------------[ cut here ]------------ <..> PC is at strlen+0x10/0x90 LR is at getname_kernel+0x2c/0xf4 <..> strlen+0x10/0x90 kern_path+0x28/0x4c fuse_dev_do_write+0x5b8/0x694 fuse_dev_write+0x74/0x94 do_iter_readv_writev+0x80/0xb8 do_readv_writev+0xec/0x1cc vfs_writev+0x54/0x64 SyS_writev+0x64/0xe4 el0_svc_naked+0x24/0x28 To avoid this we should ensure in case of FUSE_CANONICAL_PATH, the page is null terminated. Change-Id: I33ca7cc76b4472eaa982c67bb20685df451121f5 Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> Bug: 75984715 [Daniel - small edit, using args size ] Signed-off-by: Daniel Rosenberg <drosen@google.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
When an sdcardfs dentry is destroyed, it may not yet have its fsdata initialized. It must be checked before we try to access the paths in its private data. Additionally, when cleaning up the superblock after a failure, we don't have our sb private data, so check for that case. Bug: 77923821 Change-Id: I89caf6e121ed86480b42024664453fe0031bbcf3 Signed-off-by: Daniel Rosenberg <drosen@google.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
d_make_root will call iput on failure, so we shouldn't try to do that ourselves. Signed-off-by: Daniel Rosenberg <drosen@google.com> Bug: 77923821 Change-Id: I1abb4afb0f894ab917b7c6be8c833676f436beb7 Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: Daniel Rosenberg <drosen@google.com> Bug: 77923821 Change-Id: I1705bfd146009561d2d1da5f0e6a342ec6932a1c Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Noticed the following warning: WARNING: at ../../../../../../kernel/oneplus/msm8974/drivers/video/msm/mdss/mdss_livedisplay.c:145 mdss_livedisplay_worker+0x494/0x580() [<c0110b0c>] (unwind_backtrace+0x0/0x160) from [<c01c0f8c>] (warn_slowpath_null+0x40/0x64) [<c01c0f8c>] (warn_slowpath_null+0x40/0x64) from [<c04d03f0>] (mdss_livedisplay_worker+0x494/0x580) [<c04d03f0>] (mdss_livedisplay_worker+0x494/0x580) from [<c01df1b8>] (process_one_work+0x174/0x4f4) [<c01df1b8>] (process_one_work+0x174/0x4f4) from [<c01dfd7c>] (worker_thread+0x1ac/0x44c) [<c01dfd7c>] (worker_thread+0x1ac/0x44c) from [<c01e6598>] (kthread+0xc8/0xd4) [<c01e6598>] (kthread+0xc8/0xd4) from [<c010a824>] (kernel_thread_exit+0x0/0x8) OPO-713 Change-Id: I0f0ca1bdfd27f2196b4ab9d978653a39515547d3 Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Certain usecases like camera are constantly allocating and freeing binder buffers beyond the first 4k resulting in mmap_sem contention. If we expand the allocated range from 4k to something higher, we can reduce the contention. Tests show that 6 pages is enough to cause very little update_page_range operations and reduces contention. Bug: 36727951 Change-Id: I28bc3fb9b33c764c257e28487712fce2a3c1078b Reported-by: Tim Murray <timmurray@google.com> Signed-off-by: Joel Fernandes <joelaf@google.com> Pre-allocate 1 instead of 6 pages as in the original patch, as we use this pre-allocated page to prevent the first page from getting unpinned after removing the buffer headers, rather than pinning pages to speedup larger transactions. Change-Id: I7c3e4884a9538ecfd86601d31c5bcfd6611d37a4 Signed-off-by: Sherry Yang <sherryy@android.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
array_index_nospec() is proposed as a generic mechanism to mitigate against Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks via speculative execution. The array_index_nospec() implementation is expected to be safe for current generation CPUs across multiple architectures (ARM, x86). Based on an original implementation by Linus Torvalds, tweaked to remove speculative flows by Alexei Starovoitov, and tweaked again by Linus to introduce an x86 assembly implementation for the mask generation. Change-Id: Id28afe5e117369ab52a9400c2cb7d639630f3a08 Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org> Co-developed-by: Alexei Starovoitov <ast@kernel.org> Suggested-by: Cyril Novikov <cnovikov@lynx.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: gregkh@linuxfoundation.org Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727414229.33451.18411580953862676575.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
For architectures providing their own implementation of array_index_mask_nospec() in asm/barrier.h, attempting to use WARN_ONCE() to complain about out-of-range parameters using WARN_ON() results in a mess of mutually-dependent include files. Rather than unpick the dependencies, simply have the core code in nospec.h perform the checking for us. Change-Id: I36857abc8226fcdfd9c9014e3ffee17f9dc2cbca Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/1517840166-15399-1-git-send-email-will.deacon@arm.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
There are multiple problems with the dynamic sanity checking in array_index_nospec_mask_check(): * It causes unnecessary overhead in the 32-bit case since integer sized @index values will no longer cause the check to be compiled away like in the 64-bit case. * In the 32-bit case it may trigger with user controllable input when the expectation is that should only trigger during development of new kernel enabling. * The macro reuses the input parameter in multiple locations which is broken if someone passes an expression like 'index++' to array_index_nospec(). Change-Id: I845dbcb830b4d72cf7f0b835bfa64476d3763268 Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/151881604278.17395.6605847763178076520.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
The last expression in a statement expression need not be a bare variable, quoting gcc docs The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. and we already use that in e.g. the min/max macros which end with a ternary expression. This way, we can allow index to have const-qualified type, which will in some cases avoid the need for introducing a local copy of index of non-const qualified type. That, in turn, can prevent readers not familiar with the internals of array_index_nospec from wondering about the seemingly redundant extra variable, and I think that's worthwhile considering how confusing the whole _nospec business is. The expression _i&_mask has type unsigned long (since that is the type of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to that), so in order not to change the type of the whole expression, add a cast back to typeof(_i). Change-Id: I1fcaea6268a40e10c67d58e906d757b5bce7e8d0 Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arch@vger.kernel.org Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/151881604837.17395.10812767547837568328.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
The nospec.h header expects the per-architecture header file <asm/barrier.h> to optionally define array_index_mask_nospec(). Include that dependency to prevent inadvertent fallback to the default array_index_mask_nospec() implementation. The default implementation may not provide a full mitigation on architectures that perform data value speculation. Change-Id: Ib3bb49179541ca4f187f7ec6b91603a58db358f7 Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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: Will Deacon <will.deacon@arm.com> Cc: linux-arch@vger.kernel.org Link: http://lkml.kernel.org/r/151881605404.17395.1341935530792574707.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
The clockid argument of clockid_to_kclock() comes straight from user space via various syscalls and is used as index into the posix_clocks array. Protect it against spectre v1 array out of bounds speculation. Remove the redundant check for !posix_clock[id] as this is another source for speculation and does not provide any advantage over the return posix_clock[id] path which returns NULL in that case anyway. Change-Id: I46735b66e2b769d750e9484eb75cd2e57f1190d1 Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Dan Williams <dan.j.williams@intel.com> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: David Woodhouse <dwmw@amazon.co.uk> Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1802151718320.1296@nanos.tec.linutronix.de Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
'fd' is a user controlled value that is used as a data dependency to read from the 'fdt->fd' array. In order to avoid potential leaks of kernel memory values, block speculative execution of the instruction stream that could issue reads based on an invalid 'file *' returned from __fcheck_files. Change-Id: I148b33be036906d37393e49391d9181e5449f061 Co-developed-by: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: torvalds@linux-foundation.org Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727418500.33451.17392199002892248656.stgi t@dwillia2-desk3.amr.corp.intel.com Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Wireless drivers rely on parse_txq_params to validate that txq_params->ac is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx() handler is called. Use a new helper, array_index_nospec(), to sanitize txq_params->ac with respect to speculation. I.e. ensure that any speculation into ->conf_tx() handlers is done with a value of txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS). Change-Id: I4e81dbf507ba0f9bbde93116bc8d0cfee6ac58cc Reported-by: Christian Lamparter <chunkeey@gmail.com> Reported-by: Elena Reshetova <elena.reshetova@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Johannes Berg <johannes@sipsolutions.net> Cc: linux-arch@vger.kernel.org Cc: kernel-hardening@lists.openwall.com Cc: gregkh@linuxfoundation.org Cc: linux-wireless@vger.kernel.org Cc: torvalds@linux-foundation.org Cc: "David S. Miller" <davem@davemloft.net> Cc: alan@linux.intel.com Link: https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Add NULL pointer checking for actuator ctrl. CRs-Fixed: 2152399 Bug: 65122765 Change-Id: I2e206516e5ea1383c7396625455e1d7403df51cf Signed-off-by: Haibin Liu <haibinl@codeaurora.org>
Issue: i2c_reg_tbl may be null under error condition when set param. then, other actuator function still may use the i2c_reg_tbl as null. Fix: 1) the assignment total_steps follow on kmalloc buffer. 2) Add NULL pointer check for i2c tbl. CRs-Fixed: 2152401 Bug: 65122765 Change-Id: Ieec3d88e6dae0177787da0906f53d59ac4f5a624 Signed-off-by: Haibin Liu <haibinl@codeaurora.org> Signed-off-by: VijayaKumar T M <vtmuni@codeaurora.org>
Issue: the region index is not validated against the region size. this cause out-of-bound read on the KASAN kernel. Fix: Add restriction that region index smaller than region size. CRs-Fixed: 2153841 Bug: 65122765 Change-Id: I141bba45662769f0661c947fb642c2671578f32e Signed-off-by: Haibin Liu <haibinl@codeaurora.org> Signed-off-by: VijayaKumar T M <vtmuni@codeaurora.org>
commit a508294 upstream. parse_hid_report_descriptor() has a while (i < length) loop, which only guarantees that there's at least 1 byte in the buffer, but the loop body can read multiple bytes which causes out-of-bounds access. Bug: 69916367 Change-Id: Ic6a2fda77685b90d7642c09b20f5d57d6d48b726 Reported-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Siqi Lin <siqilin@google.com>
Parameter mdss_mdp_plane_sizes must be cleared to 0 before returning under an error condition, otherwise caller function will use the uninitialized mdss_mdp_plane_sizes values and caused incorrect operation. Bug: 71501679 Change-Id: I856b17ce9e917cc450040463ec34b7309d34b9b5 Signed-off-by: Benjamin Chan <bkchan@codeaurora.org>
The FASTRPC_IOCTL_INIT ioctl registers a pointer for later access without checking that it is a user pointer. This could allow arbitrary kernel memory access. This patch verifies that the pointer is a user pointer. Bug: 63165064 Change-Id: I936f73a2c2029f9e7ca12cc8fc06d0698e6710c0 Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org> Signed-off-by: Sean Callanan <spyffe@google.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
(cherry picked from commit a4b1b58) HID core expects the input buffers to be at least of size 4096 (HID_MAX_BUFFER_SIZE). Other sizes will result in buffer-overflows if an input-report is smaller than advertised. We could, like i2c, compute the biggest report-size instead of using HID_MAX_BUFFER_SIZE, but this will blow up if report-descriptors are changed after ->start() has been called. So lets be safe and just use the biggest buffer we have. Note that this adds an additional copy to the HIDP input path. If there is a way to make sure the skb-buf is big enough, we should use that instead. The best way would be to make hid-core honor the @SiZe argument, though, that sounds easier than it is. So lets just fix the buffer-overflows for now and afterwards look for a faster way for all transport drivers. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Bug: 65853588 Change-Id: Iec1410993a6d21dd9c88bd7669cf658b9f48f9dc Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
The buffer length is unsigned at all layers, but gets cast to int and
checked in hidp_process_report and can lead to a buffer overflow.
Switch len parameter to unsigned int to resolve issue.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Fixes: 678af93e46ac10318b54f2f0c9abbdfe75c4e078 ("HID: Bluetooth: hidp: make sure input buffers are big enough")
Bug: 65853588
Change-Id: I779ce783ae7c3bce8c5a66c0954ef31347e42cfc
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Add correct conditional check for len in dci_process_ctrl_status() to prevent buffer overflow. Bug: 70528036 Change-Id: Id73ed1c8b104428eceef0544ce2858160cc08fd2 Signed-off-by: Sreelakshmi Gownipalli <sgownipa@codeaurora.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
when comparing a signed value vs sizeof, make sure it's >= 0 so that when promoted to signed for comparison it won't lead to unexpected results. Bug: 70528036 Change-Id: I99a1220598e67e3ce5c99d425e84c79639121838 Signed-off-by: Andrew Chant <achant@google.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Send context ID in rpc header instead of context pointer. Validate context ID received in response and get context pointer. Bug: 74237782 Change-Id: I9cfd10d0c1b25c3085b8e15c7ca1c8ff214bf10d Acked-by: Viswanatham Paduchuri <vpaduchu@qti.qualcomm.com> Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org> Signed-off-by: Steve Pfetsch <spfetsch@google.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
This reverts commit 67566ae. Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
This reverts commit a7c0792. Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
All credits to Sultanxda <sultanxda@gmail.com> Ported to OnePlus2 by Lord Boeffla (aka andip71) When the user's finger is on the touchscreen, don't process any home key button presses, as an unintended button press will cause poor UX. Ignore home key presses when the Synaptics s1302 driver is ignoring keypad presses. Signed-off-by: Sultanxda <sultanxda@gmail.com> Signed-off-by: flar2 <asegaert@gmail.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
All credits to Sultanxda <sultanxda@gmail.com> Ported to OnePlus2 by Wang Han (aka aviraxp) When the user's finger is on the touchscreen, don't process any home key button presses, as an unintended button press will cause poor UX. Ignore home key presses when the Synaptics s1302 driver is ignoring keypad presses. Signed-off-by: Sultanxda <sultanxda@gmail.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
All credits to Sultanxda <sultanxda@gmail.com> Add a trivial pointer check to prevent a null pointer dereference, since this function can be called globally. Signed-off-by: Sultanxda <sultanxda@gmail.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
* We may compile 32-bit ARM code against these kernel headers in many situations, so provide a compiler-defined method of obtaining the width of long, rather than relying on a CFLAG define which may not be set in all cases. Change-Id: Iac5e48200d70f1258ab3caca1a8f1eb6e8f7f2d3
Change-Id: I3851f40de8481ae32d43df3d96fe1fb9988233ce
… be OK now... Change-Id: I0adb8fe9c5029bad3ac52629003c3b78e9442936 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
O_TMPFILE | O_CREAT => linkat() with AT_SYMLINK_FOLLOW and /proc/self/fd/<n> as oldpath (i.e. flink()) will create a link O_TMPFILE | O_CREAT | O_EXCL => ENOENT on attempt to link those guys Change-Id: I5e28485680c3320cd0fccc0ba1bea8b963fca7fe Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
In this case we do need a bit more than usual, due to orphan list handling. Change-Id: I355e9c97e04a03f89bb760009fecc160b25caeb7 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
very similar to ext3 counterpart... Change-Id: Ibb9de458c172ad50c4c202b971cb7243c8e43c82 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[suggested by Rasmus Villemoes] make O_DIRECTORY | O_RDWR part of O_TMPFILE; that will fail on old kernels in a lot more cases than what I came up with. And make sure O_CREAT doesn't get there... Change-Id: Iaa3c8b487d44515b539150bdb5d0b749b87d3ea2 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Change-Id: I90171d1b53a4c35bfa76757ecfdfb6f95330d107 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
When we try to open a file with O_TMPFILE flag, we will trigger a bug.
The root cause is that in ext4_orphan_add() we check ->i_nlink == 0 and
this check always fails because we set ->i_nlink = 1 in
inode_init_always(). We can use the following program to trigger it:
int main(int argc, char *argv[])
{
int fd;
fd = open(argv[1], O_TMPFILE, 0666);
if (fd < 0) {
perror("open ");
return -1;
}
close(fd);
return 0;
}
The oops message looks like this:
kernel BUG at fs/ext4/namei.c:2572!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: dlci bridge stp hidp cmtp kernelcapi l2tp_ppp l2tp_netlink l2tp_core sctp libcrc32c rfcomm tun fuse nfnetli
nk can_raw ipt_ULOG can_bcm x25 scsi_transport_iscsi ipx p8023 p8022 appletalk phonet psnap vmw_vsock_vmci_transport af_key vmw_vmci rose vsock atm can netrom ax25 af_rxrpc ir
da pppoe pppox ppp_generic slhc bluetooth nfc rfkill rds caif_socket caif crc_ccitt af_802154 llc2 llc snd_hda_codec_realtek snd_hda_intel snd_hda_codec serio_raw snd_pcm pcsp
kr edac_core snd_page_alloc snd_timer snd soundcore r8169 mii sr_mod cdrom pata_atiixp radeon backlight drm_kms_helper ttm
CPU: 1 PID: 1812571 Comm: trinity-child2 Not tainted 3.11.0-rc1+ #12
Hardware name: Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H, BIOS F12a 04/23/2010
task: ffff88007dfe69a0 ti: ffff88010f7b6000 task.ti: ffff88010f7b6000
RIP: 0010:[<ffffffff8125ce69>] [<ffffffff8125ce69>] ext4_orphan_add+0x299/0x2b0
RSP: 0018:ffff88010f7b7cf8 EFLAGS: 00010202
RAX: 0000000000000000 RBX: ffff8800966d3020 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88007dfe70b8 RDI: 0000000000000001
RBP: ffff88010f7b7d40 R08: ffff880126a3c4e0 R09: ffff88010f7b7ca0
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801271fd668
R13: ffff8800966d2f78 R14: ffff88011d7089f0 R15: ffff88007dfe69a0
FS: 00007f70441a3740(0000) GS:ffff88012a800000(0000) knlGS:00000000f77c96c0
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000002834000 CR3: 0000000107964000 CR4: 00000000000007e0
DR0: 0000000000780000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Stack:
0000000000002000 00000020810b6dde 0000000000000000 ffff88011d46db00
ffff8800966d3020 ffff88011d7089f0 ffff88009c7f4c10 ffff88010f7b7f2c
ffff88007dfe69a0 ffff88010f7b7da8 ffffffff8125cfac ffff880100000004
Call Trace:
[<ffffffff8125cfac>] ext4_tmpfile+0x12c/0x180
[<ffffffff811cba78>] path_openat+0x238/0x700
[<ffffffff8100afc4>] ? native_sched_clock+0x24/0x80
[<ffffffff811cc647>] do_filp_open+0x47/0xa0
[<ffffffff811db73f>] ? __alloc_fd+0xaf/0x200
[<ffffffff811ba2e4>] do_sys_open+0x124/0x210
[<ffffffff81010725>] ? syscall_trace_enter+0x25/0x290
[<ffffffff811ba3ee>] SyS_open+0x1e/0x20
[<ffffffff816ca8d4>] tracesys+0xdd/0xe2
[<ffffffff81001001>] ? start_thread_common.constprop.6+0x1/0xa0
Code: 04 00 00 00 89 04 24 31 c0 e8 c4 77 04 00 e9 43 fe ff ff 66 25 00 d0 66 3d 00 80 0f 84 0e fe ff ff 83 7b 48 00 0f 84 04 fe ff ff <0f> 0b 49 8b 8c 24 50 07 00 00 e9 88 fe ff ff 0f 1f 84 00 00 00
Here we couldn't call clear_nlink() directly because in d_tmpfile() we
will call inode_dec_link_count() to decrease ->i_nlink. So this commit
tries to call d_tmpfile() before ext4_orphan_add() to fix this problem.
Change-Id: Ie8a8009970d1e38c6863d94296f2738918da5429
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Tested-by: Darrick J. Wong <darrick.wong@oracle.com>
Tested-by: Dave Jones <davej@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
When we try to open a file with O_TMPFILE flag, we will trigger a bug.
The root cause is that in ext4_orphan_add() we check ->i_nlink == 0 and
this check always fails because we set ->i_nlink = 1 in
inode_init_always(). We can use the following program to trigger it:
int main(int argc, char *argv[])
{
int fd;
fd = open(argv[1], O_TMPFILE, 0666);
if (fd < 0) {
perror("open ");
return -1;
}
close(fd);
return 0;
}
The oops message looks like this:
kernel: kernel BUG at fs/ext3/namei.c:1992!
kernel: invalid opcode: 0000 [#1] SMP
kernel: Modules linked in: ext4 jbd2 crc16 cpufreq_ondemand ipv6 dm_mirror dm_region_hash dm_log dm_mod parport_pc parport serio_raw sg dcdbas pcspkr i2c_i801 ehci_pci ehci_hcd button acpi_cpufreq mperf e1000e ptp pps_core ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core ext3 jbd sd_mod ahci libahci libata scsi_mod uhci_hcd
kernel: CPU: 0 PID: 2882 Comm: tst_tmpfile Not tainted 3.11.0-rc1+ #4
kernel: Hardware name: Dell Inc. OptiPlex 780 /0V4W66, BIOS A05 08/11/2010
kernel: task: ffff880112d30050 ti: ffff8801124d4000 task.ti: ffff8801124d4000
kernel: RIP: 0010:[<ffffffffa00db5ae>] [<ffffffffa00db5ae>] ext3_orphan_add+0x6a/0x1eb [ext3]
kernel: RSP: 0018:ffff8801124d5cc8 EFLAGS: 00010202
kernel: RAX: 0000000000000000 RBX: ffff880111510128 RCX: ffff8801114683a0
kernel: RDX: 0000000000000000 RSI: ffff880111510128 RDI: ffff88010fcf65a8
kernel: RBP: ffff8801124d5d18 R08: 0080000000000000 R09: ffffffffa00d3b7f
kernel: R10: ffff8801114683a0 R11: ffff8801032a2558 R12: 0000000000000000
kernel: R13: ffff88010fcf6800 R14: ffff8801032a2558 R15: ffff8801115100d8
kernel: FS: 00007f5d172b5700(0000) GS:ffff880117c00000(0000) knlGS:0000000000000000
kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
kernel: CR2: 00007f5d16df15d0 CR3: 0000000110b1d000 CR4: 00000000000407f0
kernel: Stack:
kernel: 000000000000000c ffff8801048a7dc8 ffff8801114685a8 ffffffffa00b80d7
kernel: ffff8801124d5e38 ffff8801032a2558 ffff88010ce24d68 0000000000000000
kernel: ffff88011146b300 ffff8801124d5d44 ffff8801124d5d78 ffffffffa00db7e1
kernel: Call Trace:
kernel: [<ffffffffa00b80d7>] ? journal_start+0x8c/0xbd [jbd]
kernel: [<ffffffffa00db7e1>] ext3_tmpfile+0xb2/0x13b [ext3]
kernel: [<ffffffff821076f8>] path_openat+0x11f/0x5e7
kernel: [<ffffffff821c86b4>] ? list_del+0x11/0x30
kernel: [<ffffffff82065fa2>] ? __dequeue_entity+0x33/0x38
kernel: [<ffffffff82107cd5>] do_filp_open+0x3f/0x8d
kernel: [<ffffffff82112532>] ? __alloc_fd+0x50/0x102
kernel: [<ffffffff820f9296>] do_sys_open+0x13b/0x1cd
kernel: [<ffffffff820f935c>] SyS_open+0x1e/0x20
kernel: [<ffffffff82398c02>] system_call_fastpath+0x16/0x1b
kernel: Code: 39 c7 0f 85 67 01 00 00 0f b7 03 25 00 f0 00 00 3d 00 40 00 00 74 18 3d 00 80 00 00 74 11 3d 00 a0 00 00 74 0a 83 7b 48 00 74 04 <0f> 0b eb fe 49 8b 85 50 03 00 00 4c 89 f6 48 c7 c7 c0 99 0e a0
kernel: RIP [<ffffffffa00db5ae>] ext3_orphan_add+0x6a/0x1eb [ext3]
kernel: RSP <ffff8801124d5cc8>
Here we couldn't call clear_nlink() directly because in d_tmpfile() we
will call inode_dec_link_count() to decrease ->i_nlink. So this commit
tries to call d_tmpfile() before ext4_orphan_add() to fix this problem.
Change-Id: I6e953c0a1188d2099f9202e2f8ba8145fa3531b5
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>
Cc: Al Viro <viro@zeniv.linux.org.uk>
O_TMPFILE, like O_CREAT, should respect the requested mode and should create regular files. This fixes two bugs: O_TMPFILE required privilege (because the mode ended up as 000) and it produced bogus inodes with no type. Change-Id: Ie4da9ede57e481c7edb113c5bc6329fefef41f4e Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
As comment in include/uapi/asm-generic/fcntl.h described, when introducing new O_* bits, we need to check its uniqueness in fcntl_init(). But __O_TMPFILE bit is missing. So fix it. Change-Id: I5c6ddf8ef05e96e4799bac823caa7dd60ce558dd Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
d_tmpfile() already swallowed the inode ref. Change-Id: I22411f145d675948cff55b5a8cc3c0cd3a0d484c Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
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.
Change-Id: Ib052bbc6fcc68d3060f91732a78ddbff6f71e0a6
Signed-off-by: Eric Rannaud <e@nanocritical.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* AOSP framework/base commit dca36e4e loads persistent OEM specific USB functions with respect to the current boot mode if it's neither "normal" nor "unknown". In this case if the corresponding USB function is not set, it'll be set to "none". * However, while most bootloaders report boot mode as "normal" after reboot, OnePlus and OPPO bootloader reports "reboot". The system will treat it as OEM specific boot mode and try to load specific USB functions. As the functions are not set, sys.usb.config will be set to none. * To address the problem, hack cmdline to override "reboot" boot mode with "normal", so userspace won't confuse. Change-Id: Ie01b8177f05ca27832565b301bb3ddb79af0851e Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
due to the commit by CAF in vold the allow_discards case never evaluates at all. instead of hacking vold assume that allow_discards is always true fixes: TeamWin/android_device_oneplus_oneplus2#7 (comment) test: fstrim -v /data when using dm-req-crypt hold for review before mergimg to lineage-16.0 branch Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
/proc/self/cwd with O_CREAT should fail with EISDIR. /proc/self/exe, OTOH, should fail with ENOTDIR when opened with O_DIRECTORY. Change-Id: I01c85a6a3894c6854c604f192f221175edc19867 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
note: using the mainline version instead of the version on the op2 los kernel repo because the EAS backport brought tnis code in-line with mainline Change-Id: I6e900fc3facf5a3febefe138fea7db493bc383d8 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
[ Upstream commit f15133d ] path_openat() jumps to the wrong place after do_tmpfile() - it has already done path_cleanup() (as part of path_lookupat() called by do_tmpfile()), so doing that again can lead to double fput(). Change-Id: Ia74c130ae5e379b512532c0feebea871b5f73668 Cc: stable@vger.kernel.org # v3.11+ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Remove handling of SD_SHUTDOWN to avoid multiple release. Bug: 31243641 Change-Id: I09db8adb766d2e7889443f779a716aaa2f6c09d1 Signed-off-by: Harsh Shah <harshs@codeaurora.org> Signed-off-by: Ranjith Kagathi Ananda <ranjith@codeaurora.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
This reverts commit c65b86e. Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
When the request_key() syscall is not passed a destination keyring, it links the requested key (if constructed) into the "default" request-key keyring. This should require Write permission to the keyring. However, there is actually no permission check. This can be abused to add keys to any keyring to which only Search permission is granted. This is because Search permission allows joining the keyring. keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_SESSION_KEYRING) then will set the default request-key keyring to the session keyring. Then, request_key() can be used to add keys to the keyring. Both negatively and positively instantiated keys can be added using this method. Adding negative keys is trivial. Adding a positive key is a bit trickier. It requires that either /sbin/request-key positively instantiates the key, or that another thread adds the key to the process keyring at just the right time, such that request_key() misses it initially but then finds it in construct_alloc_key(). Fix this bug by checking for Write permission to the keyring in construct_get_dest_keyring() when the default keyring is being used. We don't do the permission check for non-default keyrings because that was already done by the earlier call to lookup_user_key(). Also, request_key_and_link() is currently passed a 'struct key *' rather than a key_ref_t, so the "possessed" bit is unavailable. We also don't do the permission check for the "requestor keyring", to continue to support the use case described by commit 8bbf497 ("KEYS: Alter use of key instantiation link-to-keyring argument") where /sbin/request-key recursively calls request_key() to add keys to the original requestor's destination keyring. (I don't know of any users who actually do that, though...) Fixes: 3e30148 ("[PATCH] Keys: Make request-key create an authorisation key") Change-Id: Ifed7bd6550a2562f6e307537fd7a17d8a7279f85 Cc: <stable@vger.kernel.org> # v2.6.13+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
voice_svc_dev is allocated as a device managed resource and need not be freed since it is freed automatically. Remove the logic to free voice_svc_dev in probe failure and remove functions to avoid double free. CRs-Fixed: 2204285 Bug: 109741750 Change-Id: If4f9ca840b00448b987f5ce443f66b0923b01969 Signed-off-by: Aditya Bavanari <abavanar@codeaurora.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
When ICE is used errors during endio are not propagated properly to upper layers. Fixed. Change-Id: I5c428e4a02f7012f95e3a32486920e69b93ea3fc Signed-off-by: Andrey Markovytch <andreym@codeaurora.org> Signed-off-by: anupritaisno1 <www.anuprita804@gmail.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.