Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 15 2月, 2019 16 次提交
    • C
      pinctrl: sunxi: Correct number of IRQ banks on H6 main pin controller · 93f6fb60
      由 Chen-Yu Tsai 提交于 
      commit 10098709b4ee6f6f19f25ba81d9c6f83518c584c upstream.

The H6 main pin controller has four banks of interrupt-triggering pins.
The driver as originally submitted only specified three, but had pin
descriptions referencing a fourth bank. This results in a out-of-bounds
access into .irq_array of struct sunxi_pinctrl. This however did not
result in a crash until v4.20, with commit a66d972465d1 ("devres: Align
data[] to ARCH_KMALLOC_MINALIGN"), which changed the alignment of memory
region returned by devm_kcalloc(). The increase likely moved the
out-of-bounds access into the next, unmapped page.

With KASAN on, the bug is quite clear:

    BUG: KASAN: slab-out-of-bounds in sunxi_pinctrl_init_with_variant+0x49c/0x12b8
    Write of size 4 at addr ffff80002c680280 by task swapper/0/1

    CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc1-00016-gc480a5e6a077 #3
    Hardware name: OrangePi Lite2 (DT)
    Call trace:
     dump_backtrace+0x0/0x220
     show_stack+0x14/0x20
     dump_stack+0xac/0xd4
     print_address_description+0x60/0x25c
     kasan_report+0x14c/0x1ac
     __asan_store4+0x80/0xa0
     sunxi_pinctrl_init_with_variant+0x49c/0x12b8
     h6_pinctrl_probe+0x18/0x20
     platform_drv_probe+0x6c/0xc8
     really_probe+0x244/0x4b0
     driver_probe_device.part.4+0x11c/0x164
     __driver_attach+0x120/0x190
     bus_for_each_dev+0xe8/0x158
     driver_attach+0x30/0x40
     bus_add_driver+0x308/0x318
     driver_register+0xbc/0x1d0
     __platform_driver_register+0x7c/0x88
     h6_pinctrl_driver_init+0x18/0x20
     do_one_initcall+0xd4/0x208
     kernel_init_freeable+0x230/0x2c8
     kernel_init+0x10/0x108
     ret_from_fork+0x10/0x1c

    Allocated by task 1:
     kasan_kmalloc.part.0+0x4c/0x100
     kasan_kmalloc+0xc4/0xe8
     kasan_slab_alloc+0x14/0x20
     __kmalloc_track_caller+0x130/0x238
     devm_kmalloc+0x34/0xd0
     sunxi_pinctrl_init_with_variant+0x1d8/0x12b8
     h6_pinctrl_probe+0x18/0x20
     platform_drv_probe+0x6c/0xc8
     really_probe+0x244/0x4b0
     driver_probe_device.part.4+0x11c/0x164
     __driver_attach+0x120/0x190
     bus_for_each_dev+0xe8/0x158
     driver_attach+0x30/0x40
     bus_add_driver+0x308/0x318
     driver_register+0xbc/0x1d0
     __platform_driver_register+0x7c/0x88
     h6_pinctrl_driver_init+0x18/0x20
     do_one_initcall+0xd4/0x208
     kernel_init_freeable+0x230/0x2c8
     kernel_init+0x10/0x108
     ret_from_fork+0x10/0x1c

    Freed by task 0:
    (stack is not available)

    The buggy address belongs to the object at ffff80002c680080
     which belongs to the cache kmalloc-512 of size 512
    The buggy address is located 0 bytes to the right of
     512-byte region [ffff80002c680080, ffff80002c680280)
    The buggy address belongs to the page:
    page:ffff7e0000b1a000 count:1 mapcount:0 mapping:ffff80002e00c780 index:0xffff80002c683c80 compound_mapcount: 0
    flags: 0x10200(slab|head)
    raw: 0000000000010200 ffff80002e003a10 ffff80002e003a10 ffff80002e00c780
    raw: ffff80002c683c80 0000000000100001 00000001ffffffff 0000000000000000
    page dumped because: kasan: bad access detected

    Memory state around the buggy address:
     ffff80002c680180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff80002c680200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    >ffff80002c680280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
		       ^
     ffff80002c680300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
     ffff80002c680380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Correct the number of IRQ banks so there are no more mismatches.

Fixes: c8a83090 ("pinctrl: sunxi: add support for the Allwinner H6 main pin controller")
Cc: <stable@vger.kernel.org>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Tested-by: NNeil Armstrong <narmstrong@baylibre.com>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93f6fb60
    • G
      debugfs: fix debugfs_rename parameter checking · c619140d
      由 Greg Kroah-Hartman 提交于 
      commit d88c93f090f708c18195553b352b9f205e65418f upstream.

debugfs_rename() needs to check that the dentries passed into it really
are valid, as sometimes they are not (i.e. if the return value of
another debugfs call is passed into this one.)  So fix this up by
properly checking if the two parent directories are errors (they are
allowed to be NULL), and if the dentry to rename is not NULL or an
error.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c619140d
    • T
      samples: mei: use /dev/mei0 instead of /dev/mei · 0c548bab
      由 Tomas Winkler 提交于 
      commit c4a46acf1db3ce547d290c29e55b3476c78dd76c upstream.

The device was moved from misc device to character devices
to support multiple mei devices.

Cc: <stable@vger.kernel.org> #v4.9+
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c548bab
    • T
      mei: me: add ice lake point device id. · edd8fb55
      由 Tomas Winkler 提交于 
      commit efe814e90b98aed6d655b5a4092b9114b8b26e42 upstream.

Add icelake mei device id.

Cc: <stable@vger.kernel.org>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edd8fb55
    • D
      misc: vexpress: Off by one in vexpress_syscfg_exec() · db5f65bf
      由 Dan Carpenter 提交于 
      commit f8a70d8b889f180e6860cb1f85fed43d37844c5a upstream.

The > comparison should be >= to prevent reading beyond the end of the
func->template[] array.

(The func->template array is allocated in vexpress_syscfg_regmap_init()
and it has func->num_templates elements.)

Fixes: 974cc7b9 ("mfd: vexpress: Define the device as MFD cells")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db5f65bf
    • E
      signal: Better detection of synchronous signals · 959e46af
      由 Eric W. Biederman 提交于 
      commit 7146db3317c67b517258cb5e1b08af387da0618b upstream.

Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop failing
to deliver SIGHUP but always trying.

When the stack overflows delivery of SIGHUP fails and force_sigsegv is
called.  Unfortunately because SIGSEGV is numerically higher than
SIGHUP next_signal tries again to deliver a SIGHUP.

From a quality of implementation standpoint attempting to deliver the
timer SIGHUP signal is wrong.  We should attempt to deliver the
synchronous SIGSEGV signal we just forced.

We can make that happening in a fairly straight forward manner by
instead of just looking at the signal number we also look at the
si_code.  In particular for exceptions (aka synchronous signals) the
si_code is always greater than 0.

That still has the potential to pick up a number of asynchronous
signals as in a few cases the same si_codes that are used
for synchronous signals are also used for asynchronous signals,
and SI_KERNEL is also included in the list of possible si_codes.

Still the heuristic is much better and timer signals are definitely
excluded.  Which is enough to prevent all known ways for someone
sending a process signals fast enough to cause unexpected and
arguably incorrect behavior.

Cc: stable@vger.kernel.org
Fixes: a27341cd ("Prioritize synchronous signals over 'normal' signals")
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      959e46af
    • E
      signal: Always notice exiting tasks · f681f268
      由 Eric W. Biederman 提交于 
      commit 35634ffa1751b6efd8cf75010b509dcb0263e29b upstream.

Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER.  Ultimately causing a loop
failing to deliver SIGHUP but always trying.

Upon examination it turns out part of the problem is actually most of
the solution.  Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.

The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL.  Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.

Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death.  This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.

Cc: stable@vger.kernel.org
Tested-by: NDmitry Vyukov <dvyukov@google.com>
Reported-by: NDmitry Vyukov <dvyukov@google.com>
Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.gitSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f681f268
    • D
      iio: ti-ads8688: Update buffer allocation for timestamps · 3e17af25
      由 Dan Murphy 提交于 
      commit f214ff521fb1f861c8d7f7d0af98b06bf61b3369 upstream.

Per Jonathan Cameron, the buffer needs to allocate room for a
64 bit timestamp as well as the channels.  Change the buffer
to allocate this additional space.

Fixes: 2a864877 ("iio: adc: ti-ads8688: add trigger and buffer support")
Signed-off-by: NDan Murphy <dmurphy@ti.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e17af25
    • M
      iio: chemical: atlas-ph-sensor: correct IIO_TEMP values to millicelsius · af770a15
      由 Matt Ranostay 提交于 
      commit 0808831dc62e90023ad14ff8da4804c7846e904b upstream.

IIO_TEMP scale value for temperature was incorrect and not in millicelsius
as required by the ABI documentation.
Signed-off-by: NMatt Ranostay <matt.ranostay@konsulko.com>
Fixes: 27dec00e (iio: chemical: add Atlas pH-SM sensor support)
Cc: <stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af770a15
    • H
      iio: adc: axp288: Fix TS-pin handling · 38d28640
      由 Hans de Goede 提交于 
      commit 9bcf15f75cac3c6a00d8f8083a635de9c8537799 upstream.

Prior to this commit there were 3 issues with our handling of the TS-pin:

1) There are 2 ways how the firmware can disable monitoring of the TS-pin
for designs which do not have a temperature-sensor for the battery:
a) Clearing bit 0 of the AXP20X_ADC_EN1 register
b) Setting bit 2 of the AXP288_ADC_TS_PIN_CTRL monitoring

Prior to this commit we were unconditionally setting both bits to the
value used on devices with a TS. This causes the temperature protection to
kick in on devices without a TS, such as the Jumper ezbook v2, causing
them to not charge under Linux.

This commit fixes this by using regmap_update_bits when updating these 2
registers, leaving the 2 mentioned bits alone.

The next 2 problems are related to our handling of the current-source
for the TS-pin. The current-source used for the battery temp-sensor (TS)
is shared with the GPADC. For proper fuel-gauge and charger operation the
TS current-source needs to be permanently on. But to read the GPADC we
need to temporary switch the TS current-source to ondemand, so that the
GPADC can use it, otherwise we will always read an all 0 value.

2) Problem 2 is we were writing hardcoded values to the ADC TS pin-ctrl
register, overwriting various other unrelated bits. Specifically we were
overwriting the current-source setting for the TS and GPIO0 pins, forcing
it to 80ųA independent of its original setting. On a Chuwi Vi10 tablet
this was causing us to get a too high adc value (due to a too high
current-source) resulting in the following errors being logged:

ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
ACPI Error: Method parse/execution failed \_SB.SXP1._TMP, AE_ERROR

This commit fixes this by using regmap_update_bits to change only the
relevant bits.

3) After reading the GPADC channel we were unconditionally enabling the
TS current-source even on devices where the TS-pin is not used and the
current-source thus was off before axp288_adc_read_raw call.

This commit fixes this by making axp288_adc_set_ts a nop on devices where
the ADC is not enabled for the TS-pin.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1610545
Fixes: 3091141d ("iio: adc: axp288: Fix the GPADC pin ...")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38d28640
    • M
      tools: iio: iio_generic_buffer: make num_loops signed · 5b9ebf5b
      由 Martin Kelly 提交于 
      commit b119d3bc328e7a9574861ebe0c2110e2776c2de1 upstream.

Currently, num_loops is unsigned, but it's set by strtoll, which returns a
(signed) long long int. This could lead to overflow, and it also makes the
check "num_loops < 0" always be false, since num_loops is unsigned.
Setting num_loops to -1 to loop forever is almost working because num_loops
is getting set to a very high number, but it's technically still incorrect.

Fix this issue by making num_loops signed. This also fixes an error found
by Smatch.
Signed-off-by: NMartin Kelly <mkelly@xevo.com>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Fixes: 55dda0ab ("tools: iio: iio_generic_buffer: allow continuous looping")
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b9ebf5b
    • H
      libata: Add NOLPM quirk for SAMSUNG MZ7TE512HMHP-000L1 SSD · 88ff6a0b
      由 Hans de Goede 提交于 
      commit dd957493baa586f1431490f97f9c7c45eaf8ab10 upstream.

We've received a bugreport that using LPM with a SAMSUNG
MZ7TE512HMHP-000L1 SSD leads to system instability, we already have
a quirk for the MZ7TD256HAFV-000L9, which is also a Samsun EVO 840 /
PM851 OEM model, so it seems some of these models have a LPM issue.

This commits adds a NOLPM quirk for the model string from the new
bugeport, to avoid the reported stability issues.

Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1571330Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88ff6a0b
    • M
      mtd: rawnand: gpmi: fix MX28 bus master lockup problem · 7c5d650a
      由 Martin Kepplinger 提交于 
      commit d5d27fd9826b59979b184ec288e4812abac0e988 upstream.

Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft
reset may cause bus master lock up") for MX28 too. It has the same
problem.

Observed problem: once per 100,000+ MX28 reboots NAND read failed on
DMA timeout errors:
[    1.770823] UBI: attaching mtd3 to ubi0
[    2.768088] gpmi_nand: DMA timeout, last DMA :1
[    3.958087] gpmi_nand: BCH timeout, last DMA :1
[    4.156033] gpmi_nand: Error in ECC-based read: -110
[    4.161136] UBI warning: ubi_io_read: error -110 while reading 64
bytes from PEB 0:0, read only 0 bytes, retry
[    4.171283] step 1 error
[    4.173846] gpmi_nand: Chip: 0, Error -1

Without BCH soft reset we successfully executed 1,000,000 MX28 reboots.

I have a quote from NXP regarding this problem, from July 18th 2016:

"As the i.MX23 and i.MX28 are of the same generation, they share many
characteristics. Unfortunately, also the erratas may be shared.
In case of the documented erratas and the workarounds, you can also
apply the workaround solution of one device on the other one. This have
been reported, but I’m afraid that there are not an estimated date for
updating the Errata documents.
Please accept our apologies for any inconveniences this may cause."

Fixes: 6f2a6a52 ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems")
Cc: stable@vger.kernel.org
Signed-off-by: NManfred Schlaegl <manfred.schlaegl@ginzinger.com>
Signed-off-by: NMartin Kepplinger <martin.kepplinger@ginzinger.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFabio Estevam <festevam@gmail.com>
Acked-by: NHan Xu <han.xu@nxp.com>
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c5d650a
    • B
      mtd: spinand: Fix the error/cleanup path in spinand_init() · a72040a9
      由 Boris Brezillon 提交于 
      commit c3c7dbf4887ab3ed9d611cd1f6e16937f8700743 upstream.

The manufacturer specific initialization has already been done when
block unlocking takes place, and if anything goes wrong during this
procedure we should call spinand_manufacturer_cleanup().

Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Cc: <stable@vger.kernel.org>
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Acked-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a72040a9
    • B
      mtd: spinand: Handle the case where PROGRAM LOAD does not reset the cache · b3ce7757
      由 Boris Brezillon 提交于 
      commit 13c15e07eedf26092054c8c71f2f47edb8388310 upstream.

Looks like PROGRAM LOAD (AKA write cache) does not necessarily reset
the cache content to 0xFF (depends on vendor implementation), so we
must fill the page cache entirely even if we only want to program the
data portion of the page, otherwise we might corrupt the BBM or user
data previously programmed in OOB area.

Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Reported-by: NStefan Roese <sr@denx.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Tested-by: NStefan Roese <sr@denx.de>
Reviewed-by: NStefan Roese <sr@denx.de>
Acked-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3ce7757
    • B
      mtd: Make sure mtd->erasesize is valid even if the partition is of size 0 · 3ca59bf1
      由 Boris Brezillon 提交于 
      commit ad4635153034c20c6f6e211e2ed3fd38b658649a upstream.

Commit 33f45c44 ("mtd: Do not allow MTD devices with inconsistent
erase properties") introduced a check to make sure ->erasesize and
->_erase values are consistent with the MTD_NO_ERASE flag.
This patch did not take the 0 bytes partition case into account which
can happen when the defined partition is outside the flash device memory
range. Fix that by setting the partition erasesize to the parent
erasesize.

Fixes: 33f45c44 ("mtd: Do not allow MTD devices with inconsistent erase properties")
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: <stable@vger.kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ca59bf1
  3. 13 2月, 2019 24 次提交