- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] + pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: pipe: actually allow root to exceed the pipe buffer limits has been added to the -mm tree. Its filename is pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/pipe-actually-allow-root-to-exceed… and later at http://ozlabs.org/~akpm/mmotm/broken-out/pipe-actually-allow-root-to-exceed… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Eric Biggers <ebiggers(a)google.com> Subject: pipe: actually allow root to exceed the pipe buffer limits pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply to unprivileged users, as documented in both Documentation/sysctl/fs.txt and the pipe(7) man page. However, the capabilities are actually only checked when increasing a pipe's size using F_SETPIPE_SZ, not when creating a new pipe. Therefore, if pipe-user-pages-hard has been set, the root user can run into it and be unable to create pipes. Similarly, if pipe-user-pages-soft has been set, the root user can run into it and have their pipes limited to 1 page each. Fix this by allowing the privileged override in both cases. Link: http://lkml.kernel.org/r/20180111052902.14409-4-ebiggers3@gmail.com Fixes: 759c01142a5d ("pipe: limit the per-user amount of pages allocated in pipes") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Acked-by: Kees Cook <keescook(a)chromium.org> Acked-by: Joe Lawrence <joe.lawrence(a)redhat.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: "Luis R . Rodriguez" <mcgrof(a)kernel.org> Cc: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Mikulas Patocka <mpatocka(a)redhat.com> Cc: Willy Tarreau <w(a)1wt.eu> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/pipe.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff -puN fs/pipe.c~pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits fs/pipe.c --- a/fs/pipe.c~pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits +++ a/fs/pipe.c @@ -613,6 +613,11 @@ static bool too_many_pipe_buffers_hard(u return pipe_user_pages_hard && user_bufs >= pipe_user_pages_hard; } +static bool is_unprivileged_user(void) +{ + return !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN); +} + struct pipe_inode_info *alloc_pipe_info(void) { struct pipe_inode_info *pipe; @@ -629,12 +634,12 @@ struct pipe_inode_info *alloc_pipe_info( user_bufs = account_pipe_buffers(user, 0, pipe_bufs); - if (too_many_pipe_buffers_soft(user_bufs)) { + if (too_many_pipe_buffers_soft(user_bufs) && is_unprivileged_user()) { user_bufs = account_pipe_buffers(user, pipe_bufs, 1); pipe_bufs = 1; } - if (too_many_pipe_buffers_hard(user_bufs)) + if (too_many_pipe_buffers_hard(user_bufs) && is_unprivileged_user()) goto out_revert_acct; pipe->bufs = kcalloc(pipe_bufs, sizeof(struct pipe_buffer), @@ -1065,7 +1070,7 @@ static long pipe_set_size(struct pipe_in if (nr_pages > pipe->buffers && (too_many_pipe_buffers_hard(user_bufs) || too_many_pipe_buffers_soft(user_bufs)) && - !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN)) { + is_unprivileged_user()) { ret = -EPERM; goto out_revert_acct; } _ Patches currently in -mm which might be from ebiggers(a)google.com are userfaultfd-convert-to-use-anon_inode_getfd.patch pipe-sysctl-drop-min-parameter-from-pipe-max-size-converter.patch pipe-sysctl-remove-pipe_proc_fn.patch pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch pipe-fix-off-by-one-error-when-checking-buffer-limits.patch pipe-reject-f_setpipe_sz-with-size-over-uint_max.patch pipe-simplify-round_pipe_size.patch pipe-read-buffer-limits-atomically.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] mtd: nand: Fix nand_do_read_oob() return value

by Miquel Raynal

Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a negative error, and the MTD layer expected it. However, the trend for the NAND layer is now to return an error or a positive number of bitflips. Deciding which status to return to the user belongs to the MTD layer. Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") brought this logic to the mtd_read_oob() function while the status coming from nand_do_read_oob() (called by the ->ecc.read_oob() hook) was left unchanged. Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: stable(a)vger.kernel.org Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com> --- drivers/mtd/nand/nand_base.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 469220065b8b..88256b656072 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -3876,7 +3876,7 @@ static int nand_do_read_oob(struct mtd_info *mtd, loff_t from, if (mtd->ecc_stats.failed - stats.failed) return -EBADMSG; - return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0; + return max_bitflips; } /** -- 2.11.0

7 years, 7 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH v2 2/2] usb: dwc3: ep0: Reset TRB counter for ep0 IN

by Thinh Nguyen

Hi, On 1/11/2018 12:16 AM, Felipe Balbi wrote: > > Hi, > > Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> writes: >> In control read transfer completion handler, the driver needs to reset >> the TRB enqueue counter. Since there is one control endpoint structure >> for each direction, we must also track the TRB enqueue counter for each >> direction. Currently the driver only resets the TRB counter for control >> OUT endpoint only. Check for the data direction and properly reset the >> TRB counter from correct control endpoint. >> >> Cc: stable(a)vger.kernel.org >> Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> > > missing Fixes tag Same with this patch. There's no particular commit that it fixes. BR, Thinh

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] PCI: iproc: Fix NULL pointer dereference for BCMA

by Ray Jui

With the inbound DMA mapping supported added, the iProc PCIe driver parses DT property "dma-ranges" through call to "of_pci_dma_range_parser_init". In the case of BCMA, this results in a NULL pointer deference due to a missing of_node. Fix this by adding a guard in pcie-iproc-platform.c to only enable the inbound DMA mapping logic when DT property "dma-ranges" is present fixes: dd9d4e7498de3 ("PCI: iproc: Add inbound DMA mapping support") Reported-by: Rafał Miłecki <rafal(a)milecki.pl> Signed-off-by: Ray Jui <ray.jui(a)broadcom.com> Tested-by: Rafał Miłecki <rafal(a)milecki.pl> Cc: <stable(a)vger.kernel.org> # 4.10+ --- drivers/pci/host/pcie-iproc-platform.c | 3 +++ drivers/pci/host/pcie-iproc.c | 8 +++++--- drivers/pci/host/pcie-iproc.h | 2 ++ 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/pci/host/pcie-iproc-platform.c b/drivers/pci/host/pcie-iproc-platform.c index a5073a9..235c545 100644 --- a/drivers/pci/host/pcie-iproc-platform.c +++ b/drivers/pci/host/pcie-iproc-platform.c @@ -92,6 +92,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device *pdev) pcie->need_ob_cfg = true; } + if (of_property_read_bool(np, "dma-ranges")) + pcie->need_ib_cfg = true; + /* PHY use is optional */ pcie->phy = devm_phy_get(dev, "pcie-phy"); if (IS_ERR(pcie->phy)) { diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c index 935909b..7583606 100644 --- a/drivers/pci/host/pcie-iproc.c +++ b/drivers/pci/host/pcie-iproc.c @@ -1378,9 +1378,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res) } } - ret = iproc_pcie_map_dma_ranges(pcie); - if (ret && ret != -ENOENT) - goto err_power_off_phy; + if (pcie->need_ib_cfg) { + ret = iproc_pcie_map_dma_ranges(pcie); + if (ret && ret != -ENOENT) + goto err_power_off_phy; + } #ifdef CONFIG_ARM pcie->sysdata.private_data = pcie; diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h index a6b55ce..4ac6282 100644 --- a/drivers/pci/host/pcie-iproc.h +++ b/drivers/pci/host/pcie-iproc.h @@ -74,6 +74,7 @@ struct iproc_msi; * @ob: outbound mapping related parameters * @ob_map: outbound mapping related parameters specific to the controller * + * @need_ib_cfg: indicates SW needs to configure the inbound mapping window * @ib: inbound mapping related parameters * @ib_map: outbound mapping region related parameters * @@ -101,6 +102,7 @@ struct iproc_pcie { struct iproc_pcie_ob ob; const struct iproc_pcie_ob_map *ob_map; + bool need_ib_cfg; struct iproc_pcie_ib ib; const struct iproc_pcie_ib_map *ib_map; -- 2.1.4

7 years, 7 months

2
2
0 0

Re: [Linux-stable-mirror] [PATCH v2 1/2] usb: dwc3: gadget: Set maxpacket size for ep0 IN

by Thinh Nguyen

Hi, On 1/11/2018 12:16 AM, Felipe Balbi wrote: > > Hi, > > Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> writes: >> There are 2 control endpoint structures for DWC3. However, the driver >> only updates the OUT direction control endpoint structure during >> ConnectDone event. DWC3 driver needs to update the endpoint max packet >> size for control IN endpoint as well. If the max packet size is not >> properly set, then the driver will incorrectly calculate the data >> transfer size and fail to send ZLP for HS/FS 3-stage control read >> transfer. >> >> The fix is simply to update the max packet size for the ep0 IN direction >> during ConnectDone event. >> >> Cc: stable(a)vger.kernel.org >> Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> > > missing Fixes tag This bug has been there since the beginning. There's no particular commit that it fixes. BR, Thinh

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] WTF: patch "[PATCH] drm/i915: Fix init_clock_gating for resume" was seriously submitted to be applied to the 4.14-stable tree?

by gregkh＠linuxfoundation.org

The patch below was submitted to be applied to the 4.14-stable tree. I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst. I could be totally wrong, and if so, please respond to <stable(a)vger.kernel.org> and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 3572f04c69ed4369da5d3c65d84fb18774aa60b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Thu, 16 Nov 2017 18:02:15 +0200 Subject: [PATCH] drm/i915: Fix init_clock_gating for resume MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moving the init_clock_gating() call from intel_modeset_init_hw() to intel_modeset_gem_init() had an unintended effect of not applying some workarounds on resume. This, for example, cause some kind of corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS screen after hibernation. Fix the problem by explicitly calling init_clock_gating() from the resume path. I really hope this doesn't break something else again. At least the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549 didn't make a comeback, even after a hibernate cycle. v2: Reorder the init_clock_gating vs. modeset_init_hw to match the display reset path (Rodrigo) Cc: stable(a)vger.kernel.org Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was") Reviewed-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171116160215.25715-1-ville.… Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> (cherry picked from commit 675f7ff35bd256e65d3d0f52718d8babf5d1002a) Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 34191028bbad..7d9b07df32fa 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1714,6 +1714,7 @@ static int i915_drm_resume(struct drm_device *dev) intel_guc_resume(dev_priv); intel_modeset_init_hw(dev); + intel_init_clock_gating(dev_priv); spin_lock_irq(&dev_priv->irq_lock); if (dev_priv->display.hpd_irq_setup)

7 years, 7 months

6
11
0 0

Re: [Linux-stable-mirror] [PATCH] RDMA/rxe: Fix a race condition related to the QP error state

by Bart Van Assche

On Thu, 2018-01-11 at 21:00 +0200, Leon Romanovsky wrote: > On Thu, Jan 11, 2018 at 04:02:33PM +0000, Bart Van Assche wrote: > > On Thu, 2018-01-11 at 08:22 +0200, Leon Romanovsky wrote: > > > The proposed patch definitely decreases the chance of races, but it is not fixing them. > > > There is a chance to have change in qp state immediately after your "if ..." check. > > > > Hello Leon, > > > > Please have a look at rxe_qp_error() and you will see that the patch I posted > > is a proper fix. In the scenario you described rxe_qp_error() will trigger a > > run of rxe_completer(). > > Bart, > > What am I missing? > > CPU1 CPU2 > if (unlikely.... > <--- > /* move the qp to the error state */ > void rxe_qp_error(struct rxe_qp *qp) > { > qp->req.state = QP_STATE_ERROR; > qp->resp.state = QP_STATE_ERROR; > qp->attr.qp_state = IB_QPS_ERR; > ---> > rxe_run_task(&qp->req.task, must_sched); > > > > It is more or less the same as without "if (unlikely..." Hello Leon, In the above the part of rxe_qp_error() that I was referring to in my e-mail is missing: if (qp_type(qp) == IB_QPT_RC) rxe_run_task(&qp->comp.task, 1); Bart.

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] patch "usb: misc: usb3503: make sure reset is low for at least 100us" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: misc: usb3503: make sure reset is low for at least 100us to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From b8626f1dc29d3eee444bfaa92146ec7b291ef41c Mon Sep 17 00:00:00 2001 From: Stefan Agner <stefan(a)agner.ch> Date: Thu, 11 Jan 2018 14:47:40 +0100 Subject: usb: misc: usb3503: make sure reset is low for at least 100us When using a GPIO which is high by default, and initialize the driver in USB Hub mode, initialization fails with: [ 111.757794] usb3503 0-0008: SP_ILOCK failed (-5) The reason seems to be that the chip is not properly reset. Probe does initialize reset low, however some lines later the code already set it back high, which is not long enouth. Make sure reset is asserted for at least 100us by inserting a delay after initializing the reset pin during probe. Signed-off-by: Stefan Agner <stefan(a)agner.ch> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/misc/usb3503.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c index 465dbf68b463..f723f7b8c9ac 100644 --- a/drivers/usb/misc/usb3503.c +++ b/drivers/usb/misc/usb3503.c @@ -279,6 +279,8 @@ static int usb3503_probe(struct usb3503 *hub) if (gpio_is_valid(hub->gpio_reset)) { err = devm_gpio_request_one(dev, hub->gpio_reset, GPIOF_OUT_INIT_LOW, "usb3503 reset"); + /* Datasheet defines a hardware reset to be at least 100us */ + usleep_range(100, 10000); if (err) { dev_err(dev, "unable to request GPIO %d as reset pin (%d)\n", -- 2.15.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH stable 3.18-4.9] xhci: Fix ring leak in failure path of xhci_alloc_virt_device()

by Ben Hutchings

This is a stable-only fix for the backport of commit 5d9b70f7d52e ("xhci: Don't add a virt_dev to the devs array before it's fully allocated"). In branches that predate commit c5628a2af83a ("xhci: remove endpoint ring cache") there is an additional failure path in xhci_alloc_virt_device() where ring cache allocation fails, in which case we need to free the ring allocated for endpoint 0. Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> --- This is build-tested only. Ben. drivers/usb/host/xhci-mem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c index f7481c4e2bc9..d9363713b7f1 100644 --- a/drivers/usb/host/xhci-mem.c +++ b/drivers/usb/host/xhci-mem.c @@ -1071,7 +1071,8 @@ int xhci_alloc_virt_device(struct xhci_hcd *xhci, int slot_id, return 1; fail: - + if (dev->eps[0].ring) + xhci_ring_free(xhci, dev->eps[0].ring); if (dev->in_ctx) xhci_free_container_ctx(xhci, dev->in_ctx); if (dev->out_ctx) -- 2.15.0.rc0

7 years, 7 months

3
3
0 0

[Linux-stable-mirror] patch "USB: serial: cp210x: add new device ID ELV ALC 8xxx" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: cp210x: add new device ID ELV ALC 8xxx to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From d14ac576d10f865970bb1324d337e5e24d79aaf4 Mon Sep 17 00:00:00 2001 From: Christian Holl <cyborgx1(a)gmail.com> Date: Wed, 3 Jan 2018 19:53:02 +0100 Subject: USB: serial: cp210x: add new device ID ELV ALC 8xxx This adds the ELV ALC 8xxx Battery Charging device to the list of USB IDs of drivers/usb/serial/cp210x.c Signed-off-by: Christian Holl <cyborgx1(a)gmail.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/serial/cp210x.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c index 38814225a816..06d502b3e913 100644 --- a/drivers/usb/serial/cp210x.c +++ b/drivers/usb/serial/cp210x.c @@ -175,6 +175,7 @@ static const struct usb_device_id id_table[] = { { USB_DEVICE(0x1843, 0x0200) }, /* Vaisala USB Instrument Cable */ { USB_DEVICE(0x18EF, 0xE00F) }, /* ELV USB-I2C-Interface */ { USB_DEVICE(0x18EF, 0xE025) }, /* ELV Marble Sound Board 1 */ + { USB_DEVICE(0x18EF, 0xE030) }, /* ELV ALC 8xxx Battery Charger */ { USB_DEVICE(0x18EF, 0xE032) }, /* ELV TFD500 Data Logger */ { USB_DEVICE(0x1901, 0x0190) }, /* GE B850 CP2105 Recorder interface */ { USB_DEVICE(0x1901, 0x0193) }, /* GE B650 CP2104 PMC interface */ -- 2.15.1

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror