[lineage-17.1] Update #10
Merged
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
Member
derfelot
commented
Sep 25, 2020
•
derfelot
commented
- Merge Linux 4.4.236 kernel
- Merge CAF tag LA.UM.8.4.r1-06000-8x98.0
- Merge Linux 4.4.237 kernel
- Update WireGuard to 1.0.20200908 snapshot
Add path for routing in call uplink and downlink to MultiMedia9. Change-Id: Ide7daf112f2aaa0eb0a987d80c491e85db61fae5 Signed-off-by: Soumya Managoli <smanag@codeaurora.org>
… list Consider a scenario where a context is valid when the check is made in adreno_dispatcher_queue_cmds(), but by the time we reach _track_context(), context has been detached. We would try to delete the entry from the active context list as part of detaching the context though the entry is not added yet. Now in _track_context() the context is actually added. When the context is finally destroyed, we would be left with invalid entry in the list. Next time when a context is added, an attempt would be made to use a freed entry. Fix this by moving the entry deletion part under drawctxt lock. Change-Id: Idab7cbf10987598b3e6395b2d50c20d1990d1f02 Signed-off-by: Puranam V G Tejaswi <pvgtejas@codeaurora.org> Signed-off-by: Rohan Sethi <rohsethi@codeaurora.org>
Mark the scratch buffer as privileged so that it can only be accessed by GPU through the ringbuffer. To accomplish this, we need to: 1. Disable the shadow rptr feature. 2. Trigger RPTR update from GPU using a WHERE_AM_I packet. 3. Add support for the new ucode. Change-Id: I9b388f55f53b69028b9bbb2306cb43fd1297c52f Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org> Signed-off-by: Pranav Patel <pranavp@codeaurora.org>
In kgsl_ioctl_gpuobj_import(), user memory of type KGSL_USER_MEM_TYPE_ADDR can also lead to setting up a dma buffer. When attaching mem entry to process fails, dma buffer attachment is cleaned up only in case of KGSL_USER_MEM_TYPE_DMABUF. Similar situation can arise in case of kgsl_ioctl_map_user_mem(). Fix this by obtaining user memory type from the memdesc flags. Change-Id: I502bd0ae19241802e8f835f20391b2ce67999418 Signed-off-by: Puranam V G Tejaswi <pvgtejas@codeaurora.org> Signed-off-by: Neeraja P <neerp@codeaurora.org>
When VM_MAYWRITE flag is used during mmap(), mprotect() can be used later to change the protection of memstore to allow write. Make sure this does not happen by removing VM_MAYWRITE from the vm_flags of vma. Change-Id: I6f69f05858ea40611d512cfa796caabeaa88cdb5 Signed-off-by: Indira Biruduraju <ibirudur@codeaurora.org>
User should not be provided address out of SVM region. Return error for any such requests from user. Change-Id: If149044039b156f8192f405714f5c1a0571004e7 Signed-off-by: gkiranku <gkiranku@codeaurora.org> Signed-off-by: Sebanti Das <sebadas@codeaurora.org>
[ 31.504753] ================================================================= [ 31.512215] BUG: KASAN: global-out-of-bounds in core_ctl_set_boost+0x554/0x558 [ 31.519637] Read of size 4 at addr ffffffd0327c18f4 by task init/456 [ 31.526160] [ 31.527707] CPU: 1 PID: 456 Comm: init Tainted: G S W 5.4.12-qgki-debug-gdc9adf3559a6-dirty whatawurst#25 [ 31.537793] Hardware name: Qualcomm Technologies, Inc. 8350 venus (DT) [ 31.544499] Call trace: [ 31.547026] dump_backtrace+0x0/0x2e0 [ 31.550797] show_stack+0x14/0x20 [ 31.554220] dump_stack+0xf0/0x144 [ 31.557732] print_address_description.isra.7+0x3c/0x3d8 [ 31.563190] __kasan_report+0x158/0x23c [ 31.567144] kasan_report+0xc/0x18 [ 31.570649] __asan_report_load4_noabort+0x18/0x20 [ 31.575572] core_ctl_set_boost+0x554/0x558 [ 31.579881] z3d22747cee+0x14/0x58 [ 31.583385] z991cee001b+0x884/0xd70 [ 31.587071] sched_boost_handler+0xe4/0x108 [ 31.591381] proc_sys_call_handler+0x384/0x420 [ 31.595954] proc_sys_write+0x10/0x18 [ 31.599728] __vfs_write+0x54/0xe8 [ 31.603232] vfs_write+0x15c/0x430 [ 31.606736] ksys_write+0xe8/0x1c0 [ 31.610241] __arm64_sys_write+0x68/0x98 [ 31.614282] el0_svc_common.constprop.0+0x1c0/0x370 [ 31.619302] el0_svc_handler+0xd4/0x178 [ 31.623257] el0_svc+0x8/0xc Change-Id: I71e71d61e080c1ce948bd0400f9ebb0705a2210b Signed-off-by: Kassey Li <yingangl@codeaurora.org> Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org> [rshaha: Resolved trivial merge conflicts] Signed-off-by: Rahul Shahare <rshaha@codeaurora.org>
If we happen to have a garbage in input device's keycode table with values too big we'll end up doing clear_bit() with offset way outside of our bitmaps, damaging other objects within an input device or even outside of it. Let's add sanity checks to the returned old keycodes. Reported-by: syzbot+c769968809f9359b07aa@syzkaller.appspotmail.com Reported-by: syzbot+76f3a30e88d256644c78@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20191207212757.GA245964@dtor-ws Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Git-commit: cb222ae Change-Id: I1bd01ea3ffa0ba0e0303d19cfcc27cc39947963b Signed-off-by: Alam Md Danish <amddan@codeaurora.org> Signed-off-by: Rahul Shahare <rshaha@codeaurora.org>
add CPU dai proxy ports 8194 and 8195 required for Call Screening. Change-Id: I022dce3694216d15cb5074cb338c8baceb04c0e5 Signed-off-by: Shashi Kant Maurya <smaury@codeaurora.org>
add machine driver changes for proxy port changes. Pseudo AFE port based BE DAIs can be used for various use cases, including but not limited to voice call. Add support for BE DAI link based on pseudo port. Change-Id: I02677676f6a23a05e3f10eb2ce09f3543837417c Signed-off-by: Shashi Kant Maurya <smaury@codeaurora.org>
…riptors commit 68035c8 upstream. Way back in 2017, fuzzing the 4.14-rc2 USB stack with syzkaller kicked up the following WARNING from the UVC chain scanning code: | list_add double add: new=ffff880069084010, prev=ffff880069084010, | next=ffff880067d22298. | ------------[ cut here ]------------ | WARNING: CPU: 1 PID: 1846 at lib/list_debug.c:31 __list_add_valid+0xbd/0xf0 | Modules linked in: | CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted | 4.14.0-rc2-42613-g1488251d1a98 #238 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 | Workqueue: usb_hub_wq hub_event | task: ffff88006b01ca40 task.stack: ffff880064358000 | RIP: 0010:__list_add_valid+0xbd/0xf0 lib/list_debug.c:29 | RSP: 0018:ffff88006435ddd0 EFLAGS: 00010286 | RAX: 0000000000000058 RBX: ffff880067d22298 RCX: 0000000000000000 | RDX: 0000000000000058 RSI: ffffffff85a58800 RDI: ffffed000c86bbac | RBP: ffff88006435dde8 R08: 1ffff1000c86ba52 R09: 0000000000000000 | R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069084010 | R13: ffff880067d22298 R14: ffff880069084010 R15: ffff880067d222a0 | FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000 | CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 | CR2: 0000000020004ff2 CR3: 000000006b447000 CR4: 00000000000006e0 | Call Trace: | __list_add ./include/linux/list.h:59 | list_add_tail+0x8c/0x1b0 ./include/linux/list.h:92 | uvc_scan_chain_forward.isra.8+0x373/0x416 | drivers/media/usb/uvc/uvc_driver.c:1471 | uvc_scan_chain drivers/media/usb/uvc/uvc_driver.c:1585 | uvc_scan_device drivers/media/usb/uvc/uvc_driver.c:1769 | uvc_probe+0x77f2/0x8f00 drivers/media/usb/uvc/uvc_driver.c:2104 Looking into the output from usbmon, the interesting part is the following data packet: ffff880069c63e00 30710169 C Ci:1:002:0 0 143 = 09028f00 01030080 00090403 00000e01 00000924 03000103 7c003328 010204db If we drop the lead configuration and interface descriptors, we're left with an output terminal descriptor describing a generic display: /* Output terminal descriptor */ buf[0] 09 buf[1] 24 buf[2] 03 /* UVC_VC_OUTPUT_TERMINAL */ buf[3] 00 /* ID */ buf[4] 01 /* type == 0x0301 (UVC_OTT_DISPLAY) */ buf[5] 03 buf[6] 7c buf[7] 00 /* source ID refers to self! */ buf[8] 33 The problem with this descriptor is that it is self-referential: the source ID of 0 matches itself! This causes the 'struct uvc_entity' representing the display to be added to its chain list twice during 'uvc_scan_chain()': once via 'uvc_scan_chain_entity()' when it is processed directly from the 'dev->entities' list and then again immediately afterwards when trying to follow the source ID in 'uvc_scan_chain_forward()' Add a check before adding an entity to a chain list to ensure that the entity is not already part of a chain. Link: https://lore.kernel.org/linux-media/CAAeHK+z+Si69jUR+N-SjN9q4O+o5KFiNManqEa-PjUta7EOb7A@mail.gmail.com/ Cc: <stable@vger.kernel.org> Fixes: c0efd23 ("V4L/DVB (8145a): USB Video Class driver") Change-Id: I838d373590d2ad8722cb3e5fbf044bf497d22938 Reported-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Git-commit: 68035c8 Git-Repo: https://android.googlesource.com/kernel/common/ Signed-off-by: Rohith Kollalsi <rkollals@codeaurora.org>
This reverts commit 769b5eb. These cal types are not supported. Change-Id: Iec7d2c171c49e6e1fc4562d13d111dcdc52523fe Signed-off-by: Shashi Kant Maurya <smaury@codeaurora.org>
In platform driver volume controls, add null check for pcm pointer of struct snd_pcm_volume. Change-Id: Icc139ae7dde0d45a3101b185ac69381df9e5e6c5 Signed-off-by: xsang <xsang@codeaurora.org>
commit bce1305 upstream. It appears that a ReportSize value of zero is legal, even if a bit non-sensical. Most of the HID code seems to handle that gracefully, except when computing the total size in bytes. When fed as input to memset, this leads to some funky outcomes. Detect the corner case and correctly compute the size. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 35556be upstream. When calling into hid_map_usage(), the passed event code is blindly stored as is, even if it doesn't fit in the associated bitmap. This event code can come from a variety of sources, including devices masquerading as input devices, only a bit more "programmable". Instead of taking the event code at face value, check that it actually fits the corresponding bitmap, and if it doesn't: - spit out a warning so that we know which device is acting up - NULLify the bitmap pointer so that we catch unexpected uses Code paths that can make use of untrusted inputs can now check that the mapping was indeed correct and bail out if not. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…ation commit e48a73a upstream. Event modifiers are not mentioned in the perf record or perf stat manpages. Add them to orient new users more effectively by pointing them to the perf list manpage for details. Fixes: 2055fda ("perf list: Document precise event sampling for AMD IBS") Signed-off-by: Kim Phillips <kim.phillips@amd.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Alexey Budankov <alexey.budankov@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jin Yao <yao.jin@linux.intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Clarke <pc@us.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Tony Jones <tonyj@suse.de> Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20200901215853.276234-1-kim.phillips@amd.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e5b31ac upstream. The original count is never reused so it can be removed. Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Acked-by: Vlastimil Babka <vbabka@suse.cz> Cc: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> [dwagner: update context] Signed-off-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2923182 upstream. The CRC calculation done by genksyms is triggered when the parser hits EXPORT_SYMBOL*() macros. At this point, genksyms recursively expands the types of the function parameters, and uses that as the input for the CRC calculation. In the case of forward-declared structs, the type expands to 'UNKNOWN'. Following this, it appears that the result of the expansion of each type is cached somewhere, and seems to be re-used when/if the same type is seen again for another exported symbol in the same C file. Unfortunately, this can cause CRC 'stability' issues when a struct definition becomes visible in the middle of a C file. For example, let's assume code with the following pattern: struct foo; int bar(struct foo *arg) { /* Do work ... */ } EXPORT_SYMBOL_GPL(bar); /* This contains struct foo's definition */ #include "foo.h" int baz(struct foo *arg) { /* Do more work ... */ } EXPORT_SYMBOL_GPL(baz); Here, baz's CRC will be computed using the expansion of struct foo that was cached after bar's CRC calculation ('UNKOWN' here). But if EXPORT_SYMBOL_GPL(bar) is removed from the file (because of e.g. symbol trimming using CONFIG_TRIM_UNUSED_KSYMS), struct foo will be expanded late, during baz's CRC calculation, which now has visibility over the full struct definition, hence resulting in a different CRC for baz. The proper fix for this certainly is in genksyms, but that will take me some time to get right. In the meantime, we have seen one occurrence of this in the ehci-hcd code which hits this problem because of the way it includes C files halfway through the code together with an unlucky mix of symbol trimming. In order to workaround this, move the include done in ehci-hub.c early in ehci-hcd.c, hence making sure the struct definitions are visible to the entire file. This improves CRC stability of the ehci-hcd exports even when symbol trimming is enabled. Acked-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Quentin Perret <qperret@google.com> Link: https://lore.kernel.org/r/20200916171825.3228122-1-qperret@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 437ef80 upstream. There are 2 problems with it: 1. "<" vs expected "<<" 2. the shift number is an IOMMU page number mask, not an address mask as the IOMMU page shift is missing. This did not hit us before f1565c2 ("powerpc: use the generic dma_ops_bypass mode") because we had additional code to handle bypass mask so this chunk (almost?) never executed.However there were reports that aacraid does not work with "iommu=nobypass". After f1565c2, aacraid (and probably others which call dma_get_required_mask() before setting the mask) was unable to enable 64bit DMA and fall back to using IOMMU which was known not to work, one of the problems is double free of an IOMMU page. This fixes DMA for aacraid, both with and without "iommu=nobypass" in the kernel command line. Verified with "stress-ng -d 4". Fixes: 6a5c7be ("powerpc: Override dma_get_required_mask by platform hook and ops") Cc: stable@vger.kernel.org # v3.2+ Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200908015106.79661-1-aik@ozlabs.ru Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 72a9c67 upstream. A spanking new machine I just got has all but one USB ports wired as 3.0. Booting defconfig resulted in no keyboard or mouse, which was pretty uncool. Let's enable that -- USB3 is ubiquitous rather than an oddity. As 'y' not 'm' -- recovering from initrd problems needs a keyboard. Also add it to the 32-bit defconfig. Signed-off-by: Adam Borowski <kilobyte@angband.pl> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-usb@vger.kernel.org Link: http://lkml.kernel.org/r/20181009062803.4332-1-kilobyte@angband.pl Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/lkml/20200921162033.346434578@linuxfoundation.org/ Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Changes in 4.4.236: (63 commits)
HID: core: Correctly handle ReportSize being zero
HID: core: Sanitize event code and type when mapping input
perf record/stat: Explicitly call out event modifiers in the documentation
mm, page_alloc: remove unnecessary variable from free_pcppages_bulk
hwmon: (applesmc) check status earlier.
ceph: don't allow setlease on cephfs
s390: don't trace preemption in percpu macros
xen/xenbus: Fix granting of vmalloc'd memory
dmaengine: of-dma: Fix of_dma_router_xlate's of_dma_xlate handling
batman-adv: Avoid uninitialized chaddr when handling DHCP
batman-adv: bla: use netif_rx_ni when not in interrupt context
dmaengine: at_hdmac: check return value of of_find_device_by_node() in at_dma_xlate()
netfilter: nf_tables: incorrect enum nft_list_attributes definition
netfilter: nf_tables: fix destination register zeroing
dmaengine: pl330: Fix burst length if burst size is smaller than bus width
bnxt_en: Check for zero dir entries in NVRAM.
fix regression in "epoll: Keep a reference on files added to the check list"
tg3: Fix soft lockup when tg3_reset_task() fails.
iommu/vt-d: Serialize IOMMU GCMD register modifications
thermal: ti-soc-thermal: Fix bogus thermal shutdowns for omap4430
include/linux/log2.h: add missing () around n in roundup_pow_of_two()
btrfs: drop path before adding new uuid tree entry
btrfs: Remove redundant extent_buffer_get in get_old_root
btrfs: Remove extraneous extent_buffer_get from tree_mod_log_rewind
btrfs: set the lockdep class for log tree extent buffers
uaccess: Add non-pagefault user-space read functions
uaccess: Add non-pagefault user-space write function
btrfs: fix potential deadlock in the search ioctl
net: qmi_wwan: MDM9x30 specific power management
net: qmi_wwan: support "raw IP" mode
net: qmi_wwan: should hold RTNL while changing netdev type
net: qmi_wwan: ignore bogus CDC Union descriptors
Add Dell Wireless 5809e Gobi 4G HSPA+ Mobile Broadband Card (rev3) to qmi_wwan
qmi_wwan: Added support for Gemalto's Cinterion PHxx WWAN interface
qmi_wwan: add support for Quectel EC21 and EC25
NET: usb: qmi_wwan: add support for Telit LE922A PID 0x1040
drivers: net: usb: qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201
usb: qmi_wwan: add D-Link DWM-222 A2 device ID
net: usb: qmi_wwan: add Telit ME910 support
net: usb: qmi_wwan: add Telit 0x1050 composition
ALSA: ca0106: fix error code handling
ALSA: pcm: oss: Remove superfluous WARN_ON() for mulaw sanity check
dm cache metadata: Avoid returning cmd->bm wild pointer on error
dm thin metadata: Avoid returning cmd->bm wild pointer on error
net: refactor bind_bucket fastreuse into helper
net: initialize fastreuse on inet_inherit_port
checkpatch: fix the usage of capture group ( ... )
mm/hugetlb: fix a race between hugetlb sysctl handlers
cfg80211: regulatory: reject invalid hints
net: usb: Fix uninit-was-stored issue in asix_read_phy_addr()
ALSA: firewire-digi00x: add support for console models of Digi00x series
ALSA: firewire-digi00x: exclude Avid Adrenaline from detection
ALSA; firewire-tascam: exclude Tascam FE-8 from detection
fs/affs: use octal for permissions
affs: fix basic permission bits to actually work
ravb: Fixed to be able to unload modules
net: ethernet: mlx4: Fix memory allocation in mlx4_buddy_init()
bnxt_en: Failure to update PHY is not fatal condition.
bnxt: don't enable NAPI until rings are ready
net: usb: dm9601: Add USB ID of Keenetic Plus DSL
sctp: not disable bh in the whole sctp_get_port_local()
net: disable netpoll on fresh napis
Linux 4.4.236
* tag 'LA.UM.8.4.r1-06000-8x98.0': asoc: add new path for in call recording msm: kgsl: Fix possible use-after-free while adding context to active list msm: kgsl: Mark the scratch buffer as privileged msm: kgsl: Correctly clean up dma buffer attachment in case of error msm: kgsl: Remove VM_MAYWRITE flag to restrict mprotect msm: kgsl: skip if requested address doesn't fall in the svm range sched: Fix out of bounds issue in for_each_cluster macro Input: add safety guards to input_set_keycode() ARM: dts: msm: add CPU dai for additional proxy ports soc: add proxy ports for call screening in machine driver media: uvcvideo: Avoid cyclic entity chains due to malformed USB descriptors Revert "include: Fix for compilation issue" asoc: add missing null check for pcm pointer of snd_pcm_volume Conflicts: drivers/gpu/msm/adreno.h drivers/gpu/msm/adreno_ringbuffer.c
Changes in 4.4.237: (47 commits)
ARM: dts: socfpga: fix register entry for timer3 on Arria10
scsi: libsas: Set data_dir as DMA_NONE if libata marks qc as NODATA
drivers/net/wan/lapbether: Added needed_tailroom
firestream: Fix memleak in fs_open
drivers/net/wan/lapbether: Set network_header before transmitting
xfs: initialize the shortform attr header padding entry
drivers/net/wan/hdlc_cisco: Add hard_header_len
ALSA: hda: fix a runtime pm issue in SOF when integrated GPU is disabled
gcov: Disable gcov build with GCC 10
iio: adc: mcp3422: fix locking scope
iio: adc: mcp3422: fix locking on error path
iio:light:ltr501 Fix timestamp alignment issue.
iio:accel:bmc150-accel: Fix timestamp alignment and prevent data leak.
iio:accel:mma8452: Fix timestamp alignment and prevent data leak.
USB: core: add helpers to retrieve endpoints
staging: wlan-ng: fix out of bounds read in prism2sta_probe_usb()
btrfs: fix wrong address when faulting in pages in the search ioctl
scsi: target: iscsi: Fix hang in iscsit_access_np() when getting tpg->np_login_sem
rbd: require global CAP_SYS_ADMIN for mapping and unmapping
fbcon: remove soft scrollback code
fbcon: remove now unusued 'softback_lines' cursor() argument
vgacon: remove software scrollback support
KVM: VMX: Don't freeze guest when event delivery causes an APIC-access exit
video: fbdev: fix OOB read in vga_8planes_imageblit()
USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter
USB: serial: option: add support for SIM7070/SIM7080/SIM7090 modules
usb: Fix out of sync data toggle if a configured device is reconfigured
gcov: add support for GCC 10.1
NFSv4.1 handle ERR_DELAY error reclaiming locking state on delegation recall
scsi: pm8001: Fix memleak in pm8001_exec_internal_task_abort
scsi: lpfc: Fix FLOGI/PLOGI receive race condition in pt2pt discovery
SUNRPC: stop printk reading past end of string
rapidio: Replace 'select' DMAENGINES 'with depends on'
i2c: algo: pca: Reapply i2c bus settings after reset
MIPS: SNI: Fix MIPS_L1_CACHE_SHIFT
perf test: Free formats for perf pmu parse test
fbcon: Fix user font detection test at fbcon_resize().
MIPS: SNI: Fix spurious interrupts
USB: quirks: Add USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk for BYD zhaoxin notebook
USB: UAS: fix disconnect by unplugging a hub
usblp: fix race between disconnect() and read()
Input: i8042 - add Entroware Proteus EL07R4 to nomux and reset lists
serial: 8250_pci: Add Realtek 816a and 816b
ehci-hcd: Move include to keep CRC stable
powerpc/dma: Fix dma_map_ops::get_required_mask
x86/defconfig: Enable CONFIG_USB_XHCI_HCD=y
Linux 4.4.237
ShujathMohd
pushed a commit
to sony-msm8998/android_kernel_sony_msm8998
that referenced
this pull request
Sep 30, 2020
[ Upstream commit e24c644 ] I compiled with AddressSanitizer and I had these memory leaks while I was using the tep_parse_format function: Direct leak of 28 byte(s) in 4 object(s) allocated from: #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe) whatawurst#1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985 whatawurst#2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140 whatawurst#3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206 whatawurst#4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291 whatawurst#5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299 whatawurst#6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849 whatawurst#7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161 whatawurst#8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207 whatawurst#9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786 whatawurst#10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285 whatawurst#11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369 whatawurst#12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335 whatawurst#13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389 whatawurst#14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431 whatawurst#15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251 whatawurst#16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284 whatawurst#17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593 whatawurst#18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727 whatawurst#19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048 whatawurst#20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127 whatawurst#21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152 whatawurst#22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252 whatawurst#23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347 whatawurst#24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461 whatawurst#25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673 whatawurst#26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) The token variable in the process_dynamic_array_len function is allocated in the read_expect_type function, but is not freed before calling the read_token function. Free the token variable before calling read_token in order to plug the leak. Signed-off-by: Philippe Duplessis-Guindon <pduplessis@efficios.com> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
linckandrea
pushed a commit
to linckandrea/android_kernel_sony_msm8998-EAS
that referenced
this pull request
Oct 21, 2020
This change from commit "treewide: Fix code issues detected using GCC 8" was incorrect, and results in an out-of-bounds read. Fixes the following KASAN splat: [ 2.107219] ================================================================== [ 2.107250] BUG: KASAN: global-out-of-bounds in scsi_strcpy_devinfo+0x44/0xa0 [ 2.107265] Read of size 16 at addr 0000000000000000 by task swapper/0/1 [ 2.107275] [ 2.107293] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.200-Sultan whatawurst#10 [ 2.107305] Hardware name: Qualcomm Technologies, Inc. MSM8998 v2.1 (DT) [ 2.107316] Call trace: [ 2.107338] [<ffffffa11f28a2e0>] dump_backtrace+0x0/0x3f0 [ 2.107357] [<ffffffa11f28a6e4>] show_stack+0x14/0x20 [ 2.107379] [<ffffffa11f642510>] dump_stack+0x90/0xb0 [ 2.107399] [<ffffffa11f401c20>] print_address_description+0x90/0x294 [ 2.107417] [<ffffffa11f3f82a0>] kasan_report_error+0x160/0x250 [ 2.107432] [<ffffffa11f3f84f0>] kasan_report+0x70/0xb0 [ 2.107452] [<ffffffa11f3f6abc>] check_memory_region+0x10c/0x180 [ 2.107470] [<ffffffa11f3f6db4>] memcpy+0x34/0x70 [ 2.107487] [<ffffffa11fa57314>] scsi_strcpy_devinfo+0x44/0xa0 [ 2.107505] [<ffffffa11fa576f4>] scsi_dev_info_list_add_keyed+0xf4/0x240 [ 2.107522] [<ffffffa121628dd8>] scsi_init_devinfo+0x9c/0xec [ 2.107539] [<ffffffa121628b34>] init_scsi+0x30/0x9c [ 2.107558] [<ffffffa121601084>] do_one_initcall+0x168/0x228 [ 2.107575] [<ffffffa121601364>] kernel_init_freeable+0x220/0x2c0 [ 2.107595] [<ffffffa1207d6454>] kernel_init+0x10/0x10c [ 2.107612] [<ffffffa11f282e90>] ret_from_fork+0x10/0x40 [ 2.107622] [ 2.107632] The buggy address belongs to the variable: [ 2.107645] 0xffffffa120a42d00 [ 2.107654] [ 2.107663] Memory state around the buggy address: [ 2.107680] 0000000000000000: 00 00 00 03 fa fa fa fa 00 00 03 fa fa fa fa fa [ 2.107695] 0000000000000000: 00 00 fa fa fa fa fa fa 00 fa fa fa fa fa fa fa [ 2.107710] >0000000000000000: 00 07 fa fa fa fa fa fa 05 fa fa fa fa fa fa fa [ 2.107721] ^ [ 2.107735] 0000000000000000: 07 fa fa fa fa fa fa fa 00 07 fa fa fa fa fa fa [ 2.107750] 0000000000000000: 04 fa fa fa fa fa fa fa 00 07 fa fa fa fa fa fa [ 2.107761] ================================================================== Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
linckandrea
pushed a commit
to linckandrea/android_kernel_sony_msm8998-EAS
that referenced
this pull request
Oct 22, 2020
This change from commit "treewide: Fix code issues detected using GCC 8" was incorrect, and results in an out-of-bounds read. Fixes the following KASAN splat: [ 2.107219] ================================================================== [ 2.107250] BUG: KASAN: global-out-of-bounds in scsi_strcpy_devinfo+0x44/0xa0 [ 2.107265] Read of size 16 at addr 0000000000000000 by task swapper/0/1 [ 2.107275] [ 2.107293] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.200-Sultan whatawurst#10 [ 2.107305] Hardware name: Qualcomm Technologies, Inc. MSM8998 v2.1 (DT) [ 2.107316] Call trace: [ 2.107338] [<ffffffa11f28a2e0>] dump_backtrace+0x0/0x3f0 [ 2.107357] [<ffffffa11f28a6e4>] show_stack+0x14/0x20 [ 2.107379] [<ffffffa11f642510>] dump_stack+0x90/0xb0 [ 2.107399] [<ffffffa11f401c20>] print_address_description+0x90/0x294 [ 2.107417] [<ffffffa11f3f82a0>] kasan_report_error+0x160/0x250 [ 2.107432] [<ffffffa11f3f84f0>] kasan_report+0x70/0xb0 [ 2.107452] [<ffffffa11f3f6abc>] check_memory_region+0x10c/0x180 [ 2.107470] [<ffffffa11f3f6db4>] memcpy+0x34/0x70 [ 2.107487] [<ffffffa11fa57314>] scsi_strcpy_devinfo+0x44/0xa0 [ 2.107505] [<ffffffa11fa576f4>] scsi_dev_info_list_add_keyed+0xf4/0x240 [ 2.107522] [<ffffffa121628dd8>] scsi_init_devinfo+0x9c/0xec [ 2.107539] [<ffffffa121628b34>] init_scsi+0x30/0x9c [ 2.107558] [<ffffffa121601084>] do_one_initcall+0x168/0x228 [ 2.107575] [<ffffffa121601364>] kernel_init_freeable+0x220/0x2c0 [ 2.107595] [<ffffffa1207d6454>] kernel_init+0x10/0x10c [ 2.107612] [<ffffffa11f282e90>] ret_from_fork+0x10/0x40 [ 2.107622] [ 2.107632] The buggy address belongs to the variable: [ 2.107645] 0xffffffa120a42d00 [ 2.107654] [ 2.107663] Memory state around the buggy address: [ 2.107680] 0000000000000000: 00 00 00 03 fa fa fa fa 00 00 03 fa fa fa fa fa [ 2.107695] 0000000000000000: 00 00 fa fa fa fa fa fa 00 fa fa fa fa fa fa fa [ 2.107710] >0000000000000000: 00 07 fa fa fa fa fa fa 05 fa fa fa fa fa fa fa [ 2.107721] ^ [ 2.107735] 0000000000000000: 07 fa fa fa fa fa fa fa 00 07 fa fa fa fa fa fa [ 2.107750] 0000000000000000: 04 fa fa fa fa fa fa fa 00 07 fa fa fa fa fa fa [ 2.107761] ================================================================== Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
linckandrea
pushed a commit
to linckandrea/android_kernel_sony_msm8998-EAS
that referenced
this pull request
Feb 17, 2021
This change from commit "treewide: Fix code issues detected using GCC 8" was incorrect, and results in an out-of-bounds read. Fixes the following KASAN splat: [ 2.107219] ================================================================== [ 2.107250] BUG: KASAN: global-out-of-bounds in scsi_strcpy_devinfo+0x44/0xa0 [ 2.107265] Read of size 16 at addr 0000000000000000 by task swapper/0/1 [ 2.107275] [ 2.107293] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.200-Sultan whatawurst#10 [ 2.107305] Hardware name: Qualcomm Technologies, Inc. MSM8998 v2.1 (DT) [ 2.107316] Call trace: [ 2.107338] [<ffffffa11f28a2e0>] dump_backtrace+0x0/0x3f0 [ 2.107357] [<ffffffa11f28a6e4>] show_stack+0x14/0x20 [ 2.107379] [<ffffffa11f642510>] dump_stack+0x90/0xb0 [ 2.107399] [<ffffffa11f401c20>] print_address_description+0x90/0x294 [ 2.107417] [<ffffffa11f3f82a0>] kasan_report_error+0x160/0x250 [ 2.107432] [<ffffffa11f3f84f0>] kasan_report+0x70/0xb0 [ 2.107452] [<ffffffa11f3f6abc>] check_memory_region+0x10c/0x180 [ 2.107470] [<ffffffa11f3f6db4>] memcpy+0x34/0x70 [ 2.107487] [<ffffffa11fa57314>] scsi_strcpy_devinfo+0x44/0xa0 [ 2.107505] [<ffffffa11fa576f4>] scsi_dev_info_list_add_keyed+0xf4/0x240 [ 2.107522] [<ffffffa121628dd8>] scsi_init_devinfo+0x9c/0xec [ 2.107539] [<ffffffa121628b34>] init_scsi+0x30/0x9c [ 2.107558] [<ffffffa121601084>] do_one_initcall+0x168/0x228 [ 2.107575] [<ffffffa121601364>] kernel_init_freeable+0x220/0x2c0 [ 2.107595] [<ffffffa1207d6454>] kernel_init+0x10/0x10c [ 2.107612] [<ffffffa11f282e90>] ret_from_fork+0x10/0x40 [ 2.107622] [ 2.107632] The buggy address belongs to the variable: [ 2.107645] 0xffffffa120a42d00 [ 2.107654] [ 2.107663] Memory state around the buggy address: [ 2.107680] 0000000000000000: 00 00 00 03 fa fa fa fa 00 00 03 fa fa fa fa fa [ 2.107695] 0000000000000000: 00 00 fa fa fa fa fa fa 00 fa fa fa fa fa fa fa [ 2.107710] >0000000000000000: 00 07 fa fa fa fa fa fa 05 fa fa fa fa fa fa fa [ 2.107721] ^ [ 2.107735] 0000000000000000: 07 fa fa fa fa fa fa fa 00 07 fa fa fa fa fa fa [ 2.107750] 0000000000000000: 04 fa fa fa fa fa fa fa 00 07 fa fa fa fa fa fa [ 2.107761] ================================================================== Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Amy07i
pushed a commit
to Amy07i/android_kernel_sony_msm8998
that referenced
this pull request
Jun 12, 2022
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
whatawurst#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
whatawurst#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
whatawurst#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
whatawurst#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
whatawurst#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
whatawurst#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
whatawurst#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
whatawurst#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
whatawurst#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
whatawurst#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
whatawurst#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
whatawurst#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
whatawurst#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
whatawurst#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
whatawurst#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
whatawurst#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
whatawurst#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
whatawurst#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Amy07i
pushed a commit
to Amy07i/android_kernel_sony_msm8998
that referenced
this pull request
Aug 10, 2022
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
whatawurst#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
whatawurst#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
whatawurst#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
whatawurst#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
whatawurst#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
whatawurst#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
whatawurst#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
whatawurst#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
whatawurst#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
whatawurst#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
whatawurst#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
whatawurst#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
whatawurst#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
whatawurst#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
whatawurst#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
whatawurst#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
whatawurst#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
whatawurst#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Amy07i
pushed a commit
to Amy07i/android_kernel_sony_msm8998
that referenced
this pull request
Aug 10, 2022
[ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ]
pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message. This can cause a deadlock in the scenario reported by
syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock);
lock(&port_lock_key);
lock(&port->lock);
lock(console_owner);
As commit dbdda84 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock). But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.
Syzbot reported the following lockdep error:
======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty whatawurst#10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> whatawurst#2 (&port->lock){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
[...]
-> whatawurst#1 (&port_lock_key){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
<-- lock(&port_lock_key);
call_console_drivers kernel/printk/printk.c:1819 [inline]
console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
start_kernel+0x5e9/0x879 init/main.c:713
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}:
[...]
lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner);
vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
fail_dump lib/fault-inject.c:45 [inline]
should_fail+0x67b/0x7c0 lib/fault-inject.c:144
__should_failslab+0x152/0x1c0 mm/failslab.c:33
should_failslab+0x5/0x10 mm/slab_common.c:1224
slab_pre_alloc_hook mm/slab.h:468 [inline]
slab_alloc_node mm/slub.c:2723 [inline]
slab_alloc mm/slub.c:2807 [inline]
__kmalloc+0x72/0x300 mm/slub.c:3871
kmalloc include/linux/slab.h:582 [inline]
tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
__tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock);
n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
do_tty_write drivers/tty/tty_io.c:961 [inline]
tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
__vfs_write+0x76/0x100 fs/read_write.c:494
[...]
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &port->lock
Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com
Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com
Fixes: b6da31b ("tty: Fix data race in tty_insert_flip_string_fixed_flag")
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ariffjenong
pushed a commit
to ariffjenong/android_kernel_sony_msm8998
that referenced
this pull request
Sep 4, 2022
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]
When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.
[ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called
[ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called
...
[ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280
crash> bt
...
PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"
...
whatawurst#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
[exception RIP: dma_pool_alloc+0x1ab]
RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000
RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090
RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00
R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0
R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
whatawurst#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
whatawurst#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
whatawurst#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
whatawurst#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
whatawurst#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
whatawurst#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
whatawurst#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
whatawurst#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
whatawurst#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
whatawurst#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
whatawurst#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
whatawurst#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
whatawurst#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
whatawurst#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
whatawurst#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
whatawurst#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
whatawurst#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92
crash> net_device.state ffff89443b0c0000
state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)
To prevent this scenario, we also make sure that the netdevice is present.
Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
derfelot
pushed a commit
to derfelot/android_kernel_sony_msm8998
that referenced
this pull request
Oct 9, 2022
A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 whatawurst#10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 Signed-off-by: Carlos Llamas <cmllamas@google.com> Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org> Bug: 239630375 Link: https://lore.kernel.org/all/20220801182511.3371447-1-cmllamas@google.com/ Signed-off-by: Carlos Llamas <cmllamas@google.com> Change-Id: I5085dd0dc805a780a64c057e5819f82dd8f02868 (cherry picked from commit ae3fa5d16a02ba7c7b170e0e1ab56d6f0ba33964) CVE-2022-20421 Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
derfelot
pushed a commit
that referenced
this pull request
Oct 17, 2022
A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 Signed-off-by: Carlos Llamas <cmllamas@google.com> Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org> Bug: 239630375 Link: https://lore.kernel.org/all/20220801182511.3371447-1-cmllamas@google.com/ Signed-off-by: Carlos Llamas <cmllamas@google.com> Change-Id: I5085dd0dc805a780a64c057e5819f82dd8f02868 (cherry picked from commit ae3fa5d16a02ba7c7b170e0e1ab56d6f0ba33964) CVE-2022-20421 Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
Amy07i
pushed a commit
to Amy07i/android_kernel_sony_msm8998
that referenced
this pull request
Dec 12, 2022
A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 whatawurst#10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 Signed-off-by: Carlos Llamas <cmllamas@google.com> Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org> Bug: 239630375 Link: https://lore.kernel.org/all/20220801182511.3371447-1-cmllamas@google.com/ Signed-off-by: Carlos Llamas <cmllamas@google.com> Change-Id: I5085dd0dc805a780a64c057e5819f82dd8f02868 (cherry picked from commit ae3fa5d16a02ba7c7b170e0e1ab56d6f0ba33964) CVE-2022-20421 Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
ariffjenong
pushed a commit
to ariffjenong/android_kernel_sony_msm8998
that referenced
this pull request
Dec 16, 2022
A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 whatawurst#10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 Signed-off-by: Carlos Llamas <cmllamas@google.com> Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org> Bug: 239630375 Link: https://lore.kernel.org/all/20220801182511.3371447-1-cmllamas@google.com/ Signed-off-by: Carlos Llamas <cmllamas@google.com> Change-Id: I5085dd0dc805a780a64c057e5819f82dd8f02868 (cherry picked from commit ae3fa5d16a02ba7c7b170e0e1ab56d6f0ba33964) CVE-2022-20421 Signed-off-by: Kevin F. Haggerty <haggertk@lineageos.org>
ariffjenong
pushed a commit
to ariffjenong/android_kernel_sony_msm8998
that referenced
this pull request
Dec 16, 2022
[ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ]
pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message. This can cause a deadlock in the scenario reported by
syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock);
lock(&port_lock_key);
lock(&port->lock);
lock(console_owner);
As commit dbdda84 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock). But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.
Syzbot reported the following lockdep error:
======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty whatawurst#10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> whatawurst#2 (&port->lock){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
[...]
-> whatawurst#1 (&port_lock_key){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
<-- lock(&port_lock_key);
call_console_drivers kernel/printk/printk.c:1819 [inline]
console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
start_kernel+0x5e9/0x879 init/main.c:713
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}:
[...]
lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner);
vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
fail_dump lib/fault-inject.c:45 [inline]
should_fail+0x67b/0x7c0 lib/fault-inject.c:144
__should_failslab+0x152/0x1c0 mm/failslab.c:33
should_failslab+0x5/0x10 mm/slab_common.c:1224
slab_pre_alloc_hook mm/slab.h:468 [inline]
slab_alloc_node mm/slub.c:2723 [inline]
slab_alloc mm/slub.c:2807 [inline]
__kmalloc+0x72/0x300 mm/slub.c:3871
kmalloc include/linux/slab.h:582 [inline]
tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
__tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock);
n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
do_tty_write drivers/tty/tty_io.c:961 [inline]
tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
__vfs_write+0x76/0x100 fs/read_write.c:494
[...]
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &port->lock
Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com
Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com
Fixes: b6da31b ("tty: Fix data race in tty_insert_flip_string_fixed_flag")
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ariffjenong
pushed a commit
to ariffjenong/android_kernel_sony_msm8998
that referenced
this pull request
Dec 16, 2022
[ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ]
pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message. This can cause a deadlock in the scenario reported by
syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock);
lock(&port_lock_key);
lock(&port->lock);
lock(console_owner);
As commit dbdda84 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock). But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.
Syzbot reported the following lockdep error:
======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty whatawurst#10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> whatawurst#2 (&port->lock){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
[...]
-> whatawurst#1 (&port_lock_key){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
<-- lock(&port_lock_key);
call_console_drivers kernel/printk/printk.c:1819 [inline]
console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
start_kernel+0x5e9/0x879 init/main.c:713
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}:
[...]
lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner);
vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
fail_dump lib/fault-inject.c:45 [inline]
should_fail+0x67b/0x7c0 lib/fault-inject.c:144
__should_failslab+0x152/0x1c0 mm/failslab.c:33
should_failslab+0x5/0x10 mm/slab_common.c:1224
slab_pre_alloc_hook mm/slab.h:468 [inline]
slab_alloc_node mm/slub.c:2723 [inline]
slab_alloc mm/slub.c:2807 [inline]
__kmalloc+0x72/0x300 mm/slub.c:3871
kmalloc include/linux/slab.h:582 [inline]
tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
__tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock);
n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
do_tty_write drivers/tty/tty_io.c:961 [inline]
tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
__vfs_write+0x76/0x100 fs/read_write.c:494
[...]
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &port->lock
Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com
Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com
Fixes: b6da31b ("tty: Fix data race in tty_insert_flip_string_fixed_flag")
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ariffjenong
pushed a commit
to ariffjenong/android_kernel_sony_msm8998
that referenced
this pull request
Dec 16, 2022
[ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ]
pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message. This can cause a deadlock in the scenario reported by
syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock);
lock(&port_lock_key);
lock(&port->lock);
lock(console_owner);
As commit dbdda84 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock). But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.
Syzbot reported the following lockdep error:
======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty whatawurst#10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> whatawurst#2 (&port->lock){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
[...]
-> whatawurst#1 (&port_lock_key){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
<-- lock(&port_lock_key);
call_console_drivers kernel/printk/printk.c:1819 [inline]
console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
start_kernel+0x5e9/0x879 init/main.c:713
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}:
[...]
lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner);
vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
fail_dump lib/fault-inject.c:45 [inline]
should_fail+0x67b/0x7c0 lib/fault-inject.c:144
__should_failslab+0x152/0x1c0 mm/failslab.c:33
should_failslab+0x5/0x10 mm/slab_common.c:1224
slab_pre_alloc_hook mm/slab.h:468 [inline]
slab_alloc_node mm/slub.c:2723 [inline]
slab_alloc mm/slub.c:2807 [inline]
__kmalloc+0x72/0x300 mm/slub.c:3871
kmalloc include/linux/slab.h:582 [inline]
tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
__tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock);
n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
do_tty_write drivers/tty/tty_io.c:961 [inline]
tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
__vfs_write+0x76/0x100 fs/read_write.c:494
[...]
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &port->lock
Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com
Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com
Fixes: b6da31b ("tty: Fix data race in tty_insert_flip_string_fixed_flag")
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ariffjenong
pushed a commit
to ariffjenong/android_kernel_sony_msm8998
that referenced
this pull request
Jan 20, 2023
…g the sock [ Upstream commit 3cf7203ca620682165706f70a1b12b5194607dce ] There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 whatawurst#1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d whatawurst#2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 whatawurst#3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b whatawurst#4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb whatawurst#5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 whatawurst#6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 whatawurst#7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] whatawurst#8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 whatawurst#9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 whatawurst#10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 whatawurst#11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 whatawurst#12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde whatawurst#13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b whatawurst#14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 whatawurst#15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a whatawurst#16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 whatawurst#17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca whatawurst#18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock. Reported-by: Jianlin Shi <jishi@redhat.com> Suggested-by: Jakub Sitnicki <jakub@cloudflare.com> Fixes: 6a93cc9 ("udp-tunnel: Add a few more UDP tunnel APIs") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
Amy07i
pushed a commit
to Amy07i/android_kernel_sony_msm8998
that referenced
this pull request
Jun 17, 2023
[ Upstream commit 05bb0167c80b8f93c6a4e0451b7da9b96db990c2 ] ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 whatawurst#1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f whatawurst#1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f whatawurst#1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f whatawurst#2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d whatawurst#3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d whatawurst#4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 whatawurst#5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369 whatawurst#6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac whatawurst#7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2 whatawurst#8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 whatawurst#9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8 whatawurst#10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98 whatawurst#11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac whatawurst#12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d whatawurst#13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603 Add a simple check that avoids incrementing a pointer by zero, but otherwise behaves as before. Note that our findings are against ACPICA 20221020, but the same code exists on master. Link: acpica/acpica@770653e3 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
derfelot
pushed a commit
to derfelot/android_kernel_sony_msm8998
that referenced
this pull request
Jul 30, 2023
A transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment the reference for a node. In this case, the target proc normally releases the failed reference upon close as expected. However, if the target is dying in parallel the call will race with binder_deferred_release(), so the target could have released all of its references by now leaving the cleanup of the new failed reference unhandled. The transaction then ends and the target proc gets released making the ref->proc now a dangling pointer. Later on, ref->node is closed and we attempt to take spin_lock(&ref->proc->inner_lock), which leads to the use-after-free bug reported below. Let's fix this by cleaning up the failed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 whatawurst#10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20 Signed-off-by: Carlos Llamas <cmllamas@google.com> Acked-by: Christian Brauner (Microsoft) <brauner@kernel.org> Bug: 239630375 Link: https://lore.kernel.org/all/20220801182511.3371447-1-cmllamas@google.com/ Signed-off-by: Carlos Llamas <cmllamas@google.com> Change-Id: I5085dd0dc805a780a64c057e5819f82dd8f02868 (cherry picked from commit ae3fa5d16a02ba7c7b170e0e1ab56d6f0ba33964)
SteadyQuad
pushed a commit
to SteadyQuad/android_kernel_sony_msm8998
that referenced
this pull request
Jan 19, 2024
[ Upstream commit 6b9dbedbe3499fef862c4dff5217cf91f34e43b3 ]
pty_write() invokes kmalloc() which may invoke a normal printk() to print
failure message. This can cause a deadlock in the scenario reported by
syz-bot below:
CPU0 CPU1 CPU2
---- ---- ----
lock(console_owner);
lock(&port_lock_key);
lock(&port->lock);
lock(&port_lock_key);
lock(&port->lock);
lock(console_owner);
As commit dbdda84 ("printk: Add console owner and waiter logic to
load balance console writes") said, such deadlock can be prevented by
using printk_deferred() in kmalloc() (which is invoked in the section
guarded by the port->lock). But there are too many printk() on the
kmalloc() path, and kmalloc() can be called from anywhere, so changing
printk() to printk_deferred() is too complicated and inelegant.
Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so
that printk() will not be called, and this deadlock problem can be
avoided.
Syzbot reported the following lockdep error:
======================================================
WARNING: possible circular locking dependency detected
5.4.143-00237-g08ccc19a-dirty whatawurst#10 Not tainted
------------------------------------------------------
syz-executor.4/29420 is trying to acquire lock:
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]
ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023
but task is already holding lock:
ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> whatawurst#2 (&port->lock){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock);
tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47
serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767
serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854
serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key);
serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870
serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126
__handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156
[...]
-> whatawurst#1 (&port_lock_key){-.-.}-{2:2}:
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159
serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198
<-- lock(&port_lock_key);
call_console_drivers kernel/printk/printk.c:1819 [inline]
console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504
vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner);
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
register_console+0x8b3/0xc10 kernel/printk/printk.c:2829
univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681
console_init+0x49d/0x6d3 kernel/printk/printk.c:2915
start_kernel+0x5e9/0x879 init/main.c:713
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
-> #0 (console_owner){....}-{0:0}:
[...]
lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734
console_trylock_spinning kernel/printk/printk.c:1773 [inline] <-- lock(console_owner);
vprintk_emit+0x307/0x470 kernel/printk/printk.c:2023
vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394
printk+0xba/0xed kernel/printk/printk.c:2084
fail_dump lib/fault-inject.c:45 [inline]
should_fail+0x67b/0x7c0 lib/fault-inject.c:144
__should_failslab+0x152/0x1c0 mm/failslab.c:33
should_failslab+0x5/0x10 mm/slab_common.c:1224
slab_pre_alloc_hook mm/slab.h:468 [inline]
slab_alloc_node mm/slub.c:2723 [inline]
slab_alloc mm/slub.c:2807 [inline]
__kmalloc+0x72/0x300 mm/slub.c:3871
kmalloc include/linux/slab.h:582 [inline]
tty_buffer_alloc+0x23f/0x2a0 drivers/tty/tty_buffer.c:175
__tty_buffer_request_room+0x156/0x2a0 drivers/tty/tty_buffer.c:273
tty_insert_flip_string_fixed_flag+0x93/0x250 drivers/tty/tty_buffer.c:318
tty_insert_flip_string include/linux/tty_flip.h:37 [inline]
pty_write+0x126/0x1f0 drivers/tty/pty.c:122 <-- lock(&port->lock);
n_tty_write+0xa7a/0xfc0 drivers/tty/n_tty.c:2356
do_tty_write drivers/tty/tty_io.c:961 [inline]
tty_write+0x512/0x930 drivers/tty/tty_io.c:1045
__vfs_write+0x76/0x100 fs/read_write.c:494
[...]
other info that might help us debug this:
Chain exists of:
console_owner --> &port_lock_key --> &port->lock
Link: https://lkml.kernel.org/r/20220511061951.1114-2-zhengqi.arch@bytedance.com
Link: https://lkml.kernel.org/r/20220510113809.80626-2-zhengqi.arch@bytedance.com
Fixes: b6da31b ("tty: Fix data race in tty_insert_flip_string_fixed_flag")
Change-Id: I911074eddfab961a40cbdcbc2b4b0a4b04a70165
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
SteadyQuad
pushed a commit
to SteadyQuad/android_kernel_sony_msm8998
that referenced
this pull request
Jul 14, 2024
[ Upstream commit f8bbc07ac535593139c875ffa19af924b1084540 ] vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 whatawurst#1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 whatawurst#2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e whatawurst#3 [fffffe00003fced0] do_nmi at ffffffff8922660d whatawurst#4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 whatawurst#5 [ffffa655314979e8] io_serial_in at ffffffff89792594 whatawurst#6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 whatawurst#7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 whatawurst#8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 whatawurst#9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 whatawurst#10 [ffffa65531497ac8] console_unlock at ffffffff89316124 whatawurst#11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 whatawurst#12 [ffffa65531497b68] printk at ffffffff89318306 whatawurst#13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 whatawurst#14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] whatawurst#15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] whatawurst#16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] whatawurst#17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] whatawurst#18 [ffffa65531497f10] kthread at ffffffff892d2e72 whatawurst#19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f Fixes: ef3db4a ("tun: avoid BUG, dump packet on GSO errors") Signed-off-by: Lei Chen <lei.chen@smartx.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20240415020247.2207781-1-lei.chen@smartx.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> [uli: backport to 4.4] Signed-off-by: Ulrich Hecht <uli@kernel.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.