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

Re: [Linux-stable-mirror] [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

by Don Dutile

On 11/21/2017 11:48 AM, Leon Romanovsky wrote: > On Tue, Nov 21, 2017 at 09:36:48AM -0700, Jason Gunthorpe wrote: >> On Tue, Nov 21, 2017 at 06:34:54PM +0200, Leon Romanovsky wrote: >>> On Tue, Nov 21, 2017 at 09:04:42AM -0700, Jason Gunthorpe wrote: >>>> On Tue, Nov 21, 2017 at 09:37:27AM -0600, Daniel Jurgens wrote: >>>> >>>>> The only warning that would make sense is if the mixed ports aren't >>>>> all IB or RoCE. As you note, CX-3 can mix those two, we don't want to >>>>> see warnings about that. >>>> >>>> I would really like to see cx3 be changed to not do that, then we >>>> could finalize this issue upstream: All device ports must be the same >>>> protocol. >>> >>> I don't see the point of such artificial limitation, the users who >>> brought CX-3 have option to work in mixed mode and IMHO it is not right >>> to deprecate such ability just because it is hard for us to code for it. >> >> I don't really think it is really too user visible.. Only the device >> and port number change, but only if running in mixed mode. > > Ahh, correct me if I'm wrong, you are proposing to split mlx4_ib devices > to two devices once it is configured in mixed mode, so everyone will > have one port only. Did I understand you correctly? > Which would require splitting resources that are shared now? other splitting issue(s)? >> >> It is not just 'hard for us' it is impossible to reconcile the >> differences between ports when enforcing device level things. >> >> This keeps coming up again and again.. >> >> Jason

7 years, 7 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

by Don Dutile

On 11/21/2017 11:34 AM, Leon Romanovsky wrote: > On Tue, Nov 21, 2017 at 09:04:42AM -0700, Jason Gunthorpe wrote: >> On Tue, Nov 21, 2017 at 09:37:27AM -0600, Daniel Jurgens wrote: >> >>> The only warning that would make sense is if the mixed ports aren't >>> all IB or RoCE. As you note, CX-3 can mix those two, we don't want to >>> see warnings about that. >> >> I would really like to see cx3 be changed to not do that, then we >> could finalize this issue upstream: All device ports must be the same >> protocol. > > I don't see the point of such artificial limitation, the users who > brought CX-3 have option to work in mixed mode and IMHO it is not right > to deprecate such ability just because it is hard for us to code for it. > We use cx-3 (& cx-4 & cx-5) in mixed mode all over our RDMA cluster. Loosing that feature is not an option. > Thanks > >> >> Jason

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH rdma-rc 1/2] IB/core: Only enforce security for InfiniBand

by Jason Gunthorpe

On Tue, Nov 21, 2017 at 06:48:02PM +0200, Leon Romanovsky wrote: > On Tue, Nov 21, 2017 at 09:36:48AM -0700, Jason Gunthorpe wrote: > Ahh, correct me if I'm wrong, you are proposing to split mlx4_ib devices > to two devices once it is configured in mixed mode, so everyone will > have one port only. Did I understand you correctly? Right, but only for mixed mode. dual port roce or dual port ib is not altered. Jason

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH linux-4.9.y] dmaengine: dmatest: warn user when dma test times out

by Adam Wallis

From: Adam Wallis <awallis(a)codeaurora.org> commit a9df21e34b422f79d9a9fa5c3eff8c2a53491be6 upstream. This patch was backported and only needed a line adjustment. Commit adfa543e7314 ("dmatest: don't use set_freezable_with_signal()") introduced a bug (that is in fact documented by the patch commit text) that leaves behind a dangling pointer. Since the done_wait structure is allocated on the stack, future invocations to the DMATEST can produce undesirable results (e.g., corrupted spinlocks). Ideally, this would be cleaned up in the thread handler, but at the very least, the kernel is left in a very precarious scenario that can lead to some long debug sessions when the crash comes later. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197605 Signed-off-by: Adam Wallis <awallis(a)codeaurora.org> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- drivers/dma/dmatest.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c index cf76fc6..fbb7551 100644 --- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -666,6 +666,7 @@ static int dmatest_func(void *data) * free it this time?" dancing. For now, just * leave it dangling. */ + WARN(1, "dmatest: Kernel stack may be corrupted!!\n"); dmaengine_unmap_put(um); result("test timed out", total_tests, src_off, dst_off, len, 0); -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] Patch "serial: omap: Fix EFR write on RTS deassertion" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: omap: Fix EFR write on RTS deassertion to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-omap-fix-efr-write-on-rts-deassertion.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2a71de2f7366fb1aec632116d0549ec56d6a3940 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Sat, 21 Oct 2017 10:50:18 +0200 Subject: serial: omap: Fix EFR write on RTS deassertion From: Lukas Wunner <lukas(a)wunner.de> commit 2a71de2f7366fb1aec632116d0549ec56d6a3940 upstream. Commit 348f9bb31c56 ("serial: omap: Fix RTS handling") sought to enable auto RTS upon manual RTS assertion and disable it on deassertion. However it seems the latter was done incorrectly, it clears all bits in the Extended Features Register *except* auto RTS. Fixes: 348f9bb31c56 ("serial: omap: Fix RTS handling") Cc: Peter Hurley <peter(a)hurleysoftware.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -693,7 +693,7 @@ static void serial_omap_set_mctrl(struct if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS)) up->efr |= UART_EFR_RTS; else - up->efr &= UART_EFR_RTS; + up->efr &= ~UART_EFR_RTS; serial_out(up, UART_EFR, up->efr); serial_out(up, UART_LCR, lcr); Patches currently in stable-queue which might be from lukas(a)wunner.de are queue-4.9/serial-omap-fix-efr-write-on-rts-deassertion.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: 8250_fintek: Fix finding base_port with activated SuperIO" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_fintek: Fix finding base_port with activated SuperIO to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250_fintek-fix-finding-base_port-with-activated-superio.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd97e66c5529046e989a0879c3bb58fddb592c71 Mon Sep 17 00:00:00 2001 From: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com> Date: Tue, 17 Oct 2017 14:23:08 +0800 Subject: serial: 8250_fintek: Fix finding base_port with activated SuperIO From: Ji-Ze Hong (Peter Hong) <hpeter(a)gmail.com> commit fd97e66c5529046e989a0879c3bb58fddb592c71 upstream. The SuperIO will be configured at boot time by BIOS, but some BIOS will not deactivate the SuperIO when the end of configuration. It'll lead to mismatch for pdata->base_port in probe_setup_port(). So we'll deactivate all SuperIO before activate special base_port in fintek_8250_enter_key(). Tested on iBASE MI802. Tested-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel(a)gmail.com> Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel(a)gmail.com> Reviewd-by: Alan Cox <alan(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_fintek.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/tty/serial/8250/8250_fintek.c +++ b/drivers/tty/serial/8250/8250_fintek.c @@ -54,6 +54,9 @@ static int fintek_8250_enter_key(u16 bas if (!request_muxed_region(base_port, 2, "8250_fintek")) return -EBUSY; + /* Force to deactive all SuperIO in this base_port */ + outb(EXIT_KEY, base_port + ADDR_PORT); + outb(key, base_port + ADDR_PORT); outb(key, base_port + ADDR_PORT); return 0; Patches currently in stable-queue which might be from hpeter(a)gmail.com are queue-4.9/serial-8250_fintek-fix-finding-base_port-with-activated-superio.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: dh - fix memleak in setkey" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: dh - fix memleak in setkey to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-dh-fix-memleak-in-setkey.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ee34e2644a78e2561742bea8c4bdcf83cabf90a7 Mon Sep 17 00:00:00 2001 From: Tudor-Dan Ambarus <tudor.ambarus(a)microchip.com> Date: Thu, 25 May 2017 10:18:07 +0300 Subject: crypto: dh - fix memleak in setkey From: Tudor-Dan Ambarus <tudor.ambarus(a)microchip.com> commit ee34e2644a78e2561742bea8c4bdcf83cabf90a7 upstream. setkey can be called multiple times during the existence of the transformation object. In case of multiple setkey calls, the old key was not freed and we leaked memory. Free the old MPI key if any. Signed-off-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/dh.c | 3 +++ 1 file changed, 3 insertions(+) --- a/crypto/dh.c +++ b/crypto/dh.c @@ -84,6 +84,9 @@ static int dh_set_secret(struct crypto_k struct dh_ctx *ctx = dh_get_ctx(tfm); struct dh params; + /* Free the old MPI key if any */ + dh_free_ctx(ctx); + if (crypto_dh_decode_key(buf, len, &params) < 0) return -EINVAL; Patches currently in stable-queue which might be from tudor.ambarus(a)microchip.com are queue-4.9/crypto-dh-fix-memleak-in-setkey.patch queue-4.9/crypto-dh-fix-double-free-of-ctx-p.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ima: do not update security.ima if appraisal status is not INTEGRITY_PASS" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ima: do not update security.ima if appraisal status is not INTEGRITY_PASS to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb Mon Sep 17 00:00:00 2001 From: Roberto Sassu <roberto.sassu(a)huawei.com> Date: Tue, 7 Nov 2017 11:37:07 +0100 Subject: ima: do not update security.ima if appraisal status is not INTEGRITY_PASS From: Roberto Sassu <roberto.sassu(a)huawei.com> commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream. Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters") moved the call of ima_file_check() from may_open() to do_filp_open() at a point where the file descriptor is already opened. This breaks the assumption made by IMA that file descriptors being closed belong to files whose access was granted by ima_file_check(). The consequence is that security.ima and security.evm are updated with good values, regardless of the current appraisal status. For example, if a file does not have security.ima, IMA will create it after opening the file for writing, even if access is denied. Access to the file will be allowed afterwards. Avoid this issue by checking the appraisal status before updating security.ima. Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/integrity/ima/ima_appraise.c | 3 +++ 1 file changed, 3 insertions(+) --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -303,6 +303,9 @@ void ima_update_xattr(struct integrity_i if (iint->flags & IMA_DIGSIG) return; + if (iint->ima_file_status != INTEGRITY_PASS) + return; + rc = ima_collect_measurement(iint, file, NULL, 0, ima_hash_algo); if (rc < 0) return; Patches currently in stable-queue which might be from roberto.sassu(a)huawei.com are queue-4.9/ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: dh - Fix double free of ctx->p" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: dh - Fix double free of ctx->p to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-dh-fix-double-free-of-ctx-p.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 12d41a023efb01b846457ccdbbcbe2b65a87d530 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Sun, 5 Nov 2017 18:30:44 -0800 Subject: crypto: dh - Fix double free of ctx->p From: Eric Biggers <ebiggers(a)google.com> commit 12d41a023efb01b846457ccdbbcbe2b65a87d530 upstream. When setting the secret with the software Diffie-Hellman implementation, if allocating 'g' failed (e.g. if it was longer than MAX_EXTERN_MPI_BITS), then 'p' was freed twice: once immediately, and once later when the crypto_kpp tfm was destroyed. Fix it by using dh_free_ctx() (renamed to dh_clear_ctx()) in the error paths, as that correctly sets the pointers to NULL. KASAN report: MPI: mpi too large (32760 bits) ================================================================== BUG: KASAN: use-after-free in mpi_free+0x131/0x170 Read of size 4 at addr ffff88006c7cdf90 by task reproduce_doubl/367 CPU: 1 PID: 367 Comm: reproduce_doubl Not tainted 4.14.0-rc7-00040-g05298abde6fe #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: dump_stack+0xb3/0x10b ? mpi_free+0x131/0x170 print_address_description+0x79/0x2a0 ? mpi_free+0x131/0x170 kasan_report+0x236/0x340 ? akcipher_register_instance+0x90/0x90 __asan_report_load4_noabort+0x14/0x20 mpi_free+0x131/0x170 ? akcipher_register_instance+0x90/0x90 dh_exit_tfm+0x3d/0x140 crypto_kpp_exit_tfm+0x52/0x70 crypto_destroy_tfm+0xb3/0x250 __keyctl_dh_compute+0x640/0xe90 ? kasan_slab_free+0x12f/0x180 ? dh_data_from_key+0x240/0x240 ? key_create_or_update+0x1ee/0xb20 ? key_instantiate_and_link+0x440/0x440 ? lock_contended+0xee0/0xee0 ? kfree+0xcf/0x210 ? SyS_add_key+0x268/0x340 keyctl_dh_compute+0xb3/0xf1 ? __keyctl_dh_compute+0xe90/0xe90 ? SyS_add_key+0x26d/0x340 ? entry_SYSCALL_64_fastpath+0x5/0xbe ? trace_hardirqs_on_caller+0x3f4/0x560 SyS_keyctl+0x72/0x2c0 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x43ccf9 RSP: 002b:00007ffeeec96158 EFLAGS: 00000246 ORIG_RAX: 00000000000000fa RAX: ffffffffffffffda RBX: 000000000248b9b9 RCX: 000000000043ccf9 RDX: 00007ffeeec96170 RSI: 00007ffeeec96160 RDI: 0000000000000017 RBP: 0000000000000046 R08: 0000000000000000 R09: 0248b9b9143dc936 R10: 0000000000001000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000409670 R14: 0000000000409700 R15: 0000000000000000 Allocated by task 367: save_stack_trace+0x16/0x20 kasan_kmalloc+0xeb/0x180 kmem_cache_alloc_trace+0x114/0x300 mpi_alloc+0x4b/0x230 mpi_read_raw_data+0xbe/0x360 dh_set_secret+0x1dc/0x460 __keyctl_dh_compute+0x623/0xe90 keyctl_dh_compute+0xb3/0xf1 SyS_keyctl+0x72/0x2c0 entry_SYSCALL_64_fastpath+0x1f/0xbe Freed by task 367: save_stack_trace+0x16/0x20 kasan_slab_free+0xab/0x180 kfree+0xb5/0x210 mpi_free+0xcb/0x170 dh_set_secret+0x2d7/0x460 __keyctl_dh_compute+0x623/0xe90 keyctl_dh_compute+0xb3/0xf1 SyS_keyctl+0x72/0x2c0 entry_SYSCALL_64_fastpath+0x1f/0xbe Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Reviewed-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/dh.c | 33 +++++++++++++-------------------- 1 file changed, 13 insertions(+), 20 deletions(-) --- a/crypto/dh.c +++ b/crypto/dh.c @@ -21,19 +21,12 @@ struct dh_ctx { MPI xa; }; -static inline void dh_clear_params(struct dh_ctx *ctx) +static void dh_clear_ctx(struct dh_ctx *ctx) { mpi_free(ctx->p); mpi_free(ctx->g); - ctx->p = NULL; - ctx->g = NULL; -} - -static void dh_free_ctx(struct dh_ctx *ctx) -{ - dh_clear_params(ctx); mpi_free(ctx->xa); - ctx->xa = NULL; + memset(ctx, 0, sizeof(*ctx)); } /* @@ -71,10 +64,8 @@ static int dh_set_params(struct dh_ctx * return -EINVAL; ctx->g = mpi_read_raw_data(params->g, params->g_size); - if (!ctx->g) { - mpi_free(ctx->p); + if (!ctx->g) return -EINVAL; - } return 0; } @@ -85,21 +76,23 @@ static int dh_set_secret(struct crypto_k struct dh params; /* Free the old MPI key if any */ - dh_free_ctx(ctx); + dh_clear_ctx(ctx); if (crypto_dh_decode_key(buf, len, &params) < 0) - return -EINVAL; + goto err_clear_ctx; if (dh_set_params(ctx, &params) < 0) - return -EINVAL; + goto err_clear_ctx; ctx->xa = mpi_read_raw_data(params.key, params.key_size); - if (!ctx->xa) { - dh_clear_params(ctx); - return -EINVAL; - } + if (!ctx->xa) + goto err_clear_ctx; return 0; + +err_clear_ctx: + dh_clear_ctx(ctx); + return -EINVAL; } static int dh_compute_value(struct kpp_request *req) @@ -157,7 +150,7 @@ static void dh_exit_tfm(struct crypto_kp { struct dh_ctx *ctx = dh_get_ctx(tfm); - dh_free_ctx(ctx); + dh_clear_ctx(ctx); } static struct kpp_alg dh = { Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/crypto-dh-fix-double-free-of-ctx-p.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: omap: Fix EFR write on RTS deassertion" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: omap: Fix EFR write on RTS deassertion to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-omap-fix-efr-write-on-rts-deassertion.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2a71de2f7366fb1aec632116d0549ec56d6a3940 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Sat, 21 Oct 2017 10:50:18 +0200 Subject: serial: omap: Fix EFR write on RTS deassertion From: Lukas Wunner <lukas(a)wunner.de> commit 2a71de2f7366fb1aec632116d0549ec56d6a3940 upstream. Commit 348f9bb31c56 ("serial: omap: Fix RTS handling") sought to enable auto RTS upon manual RTS assertion and disable it on deassertion. However it seems the latter was done incorrectly, it clears all bits in the Extended Features Register *except* auto RTS. Fixes: 348f9bb31c56 ("serial: omap: Fix RTS handling") Cc: Peter Hurley <peter(a)hurleysoftware.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -693,7 +693,7 @@ static void serial_omap_set_mctrl(struct if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS)) up->efr |= UART_EFR_RTS; else - up->efr &= UART_EFR_RTS; + up->efr &= ~UART_EFR_RTS; serial_out(up, UART_EFR, up->efr); serial_out(up, UART_LCR, lcr); Patches currently in stable-queue which might be from lukas(a)wunner.de are queue-4.4/serial-omap-fix-efr-write-on-rts-deassertion.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "arm64: fix dump_instr when PAN and UAO are in use" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled arm64: fix dump_instr when PAN and UAO are in use to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm64-fix-dump_instr-when-pan-and-uao-are-in-use.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c5cea06be060f38e5400d796e61cfc8c36e52924 Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland(a)arm.com> Date: Mon, 13 Jun 2016 11:15:14 +0100 Subject: arm64: fix dump_instr when PAN and UAO are in use From: Mark Rutland <mark.rutland(a)arm.com> commit c5cea06be060f38e5400d796e61cfc8c36e52924 upstream. If the kernel is set to show unhandled signals, and a user task does not handle a SIGILL as a result of an instruction abort, we will attempt to log the offending instruction with dump_instr before killing the task. We use dump_instr to log the encoding of the offending userspace instruction. However, dump_instr is also used to dump instructions from kernel space, and internally always switches to KERNEL_DS before dumping the instruction with get_user. When both PAN and UAO are in use, reading a user instruction via get_user while in KERNEL_DS will result in a permission fault, which leads to an Oops. As we have regs corresponding to the context of the original instruction abort, we can inspect this and only flip to KERNEL_DS if the original abort was taken from the kernel, avoiding this issue. At the same time, remove the redundant (and incorrect) comments regarding the order dump_mem and dump_instr are called in. Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: James Morse <james.morse(a)arm.com> Cc: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Reported-by: Vladimir Murzin <vladimir.murzin(a)arm.com> Tested-by: Vladimir Murzin <vladimir.murzin(a)arm.com> Fixes: 57f4959bad0a154a ("arm64: kernel: Add support for User Access Override") Signed-off-by: Will Deacon <will.deacon(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm64/kernel/traps.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -64,8 +64,7 @@ static void dump_mem(const char *lvl, co /* * We need to switch to kernel mode so that we can use __get_user - * to safely read from kernel space. Note that we now dump the - * code first, just in case the backtrace kills us. + * to safely read from kernel space. */ fs = get_fs(); set_fs(KERNEL_DS); @@ -111,21 +110,12 @@ static void dump_backtrace_entry(unsigne print_ip_sym(where); } -static void dump_instr(const char *lvl, struct pt_regs *regs) +static void __dump_instr(const char *lvl, struct pt_regs *regs) { unsigned long addr = instruction_pointer(regs); - mm_segment_t fs; char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str; int i; - /* - * We need to switch to kernel mode so that we can use __get_user - * to safely read from kernel space. Note that we now dump the - * code first, just in case the backtrace kills us. - */ - fs = get_fs(); - set_fs(KERNEL_DS); - for (i = -4; i < 1; i++) { unsigned int val, bad; @@ -139,8 +129,18 @@ static void dump_instr(const char *lvl, } } printk("%sCode: %s\n", lvl, str); +} - set_fs(fs); +static void dump_instr(const char *lvl, struct pt_regs *regs) +{ + if (!user_mode(regs)) { + mm_segment_t fs = get_fs(); + set_fs(KERNEL_DS); + __dump_instr(lvl, regs); + set_fs(fs); + } else { + __dump_instr(lvl, regs); + } } static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk) Patches currently in stable-queue which might be from mark.rutland(a)arm.com are queue-4.4/arm64-fix-dump_instr-when-pan-and-uao-are-in-use.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ima: do not update security.ima if appraisal status is not INTEGRITY_PASS" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ima: do not update security.ima if appraisal status is not INTEGRITY_PASS to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb Mon Sep 17 00:00:00 2001 From: Roberto Sassu <roberto.sassu(a)huawei.com> Date: Tue, 7 Nov 2017 11:37:07 +0100 Subject: ima: do not update security.ima if appraisal status is not INTEGRITY_PASS From: Roberto Sassu <roberto.sassu(a)huawei.com> commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream. Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters") moved the call of ima_file_check() from may_open() to do_filp_open() at a point where the file descriptor is already opened. This breaks the assumption made by IMA that file descriptors being closed belong to files whose access was granted by ima_file_check(). The consequence is that security.ima and security.evm are updated with good values, regardless of the current appraisal status. For example, if a file does not have security.ima, IMA will create it after opening the file for writing, even if access is denied. Access to the file will be allowed afterwards. Avoid this issue by checking the appraisal status before updating security.ima. Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/integrity/ima/ima_appraise.c | 3 +++ 1 file changed, 3 insertions(+) --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -297,6 +297,9 @@ void ima_update_xattr(struct integrity_i if (iint->flags & IMA_DIGSIG) return; + if (iint->ima_file_status != INTEGRITY_PASS) + return; + rc = ima_collect_measurement(iint, file, NULL, NULL); if (rc < 0) return; Patches currently in stable-queue which might be from roberto.sassu(a)huawei.com are queue-4.4/ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "tpm-dev-common: Reject too short writes" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tpm-dev-common: Reject too short writes to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tpm-dev-common-reject-too-short-writes.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ee70bc1e7b63ac8023c9ff9475d8741e397316e7 Mon Sep 17 00:00:00 2001 From: Alexander Steffen <Alexander.Steffen(a)infineon.com> Date: Fri, 8 Sep 2017 17:21:32 +0200 Subject: tpm-dev-common: Reject too short writes From: Alexander Steffen <Alexander.Steffen(a)infineon.com> commit ee70bc1e7b63ac8023c9ff9475d8741e397316e7 upstream. tpm_transmit() does not offer an explicit interface to indicate the number of valid bytes in the communication buffer. Instead, it relies on the commandSize field in the TPM header that is encoded within the buffer. Therefore, ensure that a) enough data has been written to the buffer, so that the commandSize field is present and b) the commandSize field does not announce more data than has been written to the buffer. This should have been fixed with CVE-2011-1161 long ago, but apparently a correct version of that patch never made it into the kernel. Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/tpm/tpm-dev-common.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/char/tpm/tpm-dev-common.c +++ b/drivers/char/tpm/tpm-dev-common.c @@ -110,6 +110,12 @@ ssize_t tpm_common_write(struct file *fi return -EFAULT; } + if (in_size < 6 || + in_size < be32_to_cpu(*((__be32 *) (priv->data_buffer + 2)))) { + mutex_unlock(&priv->buffer_mutex); + return -EINVAL; + } + /* atomic tpm command send and result receive. We only hold the ops * lock during this period so that the tpm can be unregistered even if * the char dev is held open. Patches currently in stable-queue which might be from Alexander.Steffen(a)infineon.com are queue-4.14/tpm-dev-common-reject-too-short-writes.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: 8250_fintek: Fix finding base_port with activated SuperIO" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_fintek: Fix finding base_port with activated SuperIO to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250_fintek-fix-finding-base_port-with-activated-superio.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd97e66c5529046e989a0879c3bb58fddb592c71 Mon Sep 17 00:00:00 2001 From: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com> Date: Tue, 17 Oct 2017 14:23:08 +0800 Subject: serial: 8250_fintek: Fix finding base_port with activated SuperIO From: Ji-Ze Hong (Peter Hong) <hpeter(a)gmail.com> commit fd97e66c5529046e989a0879c3bb58fddb592c71 upstream. The SuperIO will be configured at boot time by BIOS, but some BIOS will not deactivate the SuperIO when the end of configuration. It'll lead to mismatch for pdata->base_port in probe_setup_port(). So we'll deactivate all SuperIO before activate special base_port in fintek_8250_enter_key(). Tested on iBASE MI802. Tested-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel(a)gmail.com> Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel(a)gmail.com> Reviewd-by: Alan Cox <alan(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_fintek.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/tty/serial/8250/8250_fintek.c +++ b/drivers/tty/serial/8250/8250_fintek.c @@ -118,6 +118,9 @@ static int fintek_8250_enter_key(u16 bas if (!request_muxed_region(base_port, 2, "8250_fintek")) return -EBUSY; + /* Force to deactive all SuperIO in this base_port */ + outb(EXIT_KEY, base_port + ADDR_PORT); + outb(key, base_port + ADDR_PORT); outb(key, base_port + ADDR_PORT); return 0; Patches currently in stable-queue which might be from hpeter(a)gmail.com are queue-4.14/serial-8250_fintek-fix-finding-base_port-with-activated-superio.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: omap: Fix EFR write on RTS deassertion" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: omap: Fix EFR write on RTS deassertion to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-omap-fix-efr-write-on-rts-deassertion.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2a71de2f7366fb1aec632116d0549ec56d6a3940 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Sat, 21 Oct 2017 10:50:18 +0200 Subject: serial: omap: Fix EFR write on RTS deassertion From: Lukas Wunner <lukas(a)wunner.de> commit 2a71de2f7366fb1aec632116d0549ec56d6a3940 upstream. Commit 348f9bb31c56 ("serial: omap: Fix RTS handling") sought to enable auto RTS upon manual RTS assertion and disable it on deassertion. However it seems the latter was done incorrectly, it clears all bits in the Extended Features Register *except* auto RTS. Fixes: 348f9bb31c56 ("serial: omap: Fix RTS handling") Cc: Peter Hurley <peter(a)hurleysoftware.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -693,7 +693,7 @@ static void serial_omap_set_mctrl(struct if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS)) up->efr |= UART_EFR_RTS; else - up->efr &= UART_EFR_RTS; + up->efr &= ~UART_EFR_RTS; serial_out(up, UART_EFR, up->efr); serial_out(up, UART_LCR, lcr); Patches currently in stable-queue which might be from lukas(a)wunner.de are queue-4.14/serial-omap-fix-efr-write-on-rts-deassertion.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "rcu: Fix up pending cbs check in rcu_prepare_for_idle" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rcu: Fix up pending cbs check in rcu_prepare_for_idle to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rcu-fix-up-pending-cbs-check-in-rcu_prepare_for_idle.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 135bd1a230bb69a68c9808a7d25467318900b80a Mon Sep 17 00:00:00 2001 From: Neeraj Upadhyay <neeraju(a)codeaurora.org> Date: Mon, 7 Aug 2017 11:20:10 +0530 Subject: rcu: Fix up pending cbs check in rcu_prepare_for_idle From: Neeraj Upadhyay <neeraju(a)codeaurora.org> commit 135bd1a230bb69a68c9808a7d25467318900b80a upstream. The pending-callbacks check in rcu_prepare_for_idle() is backwards. It should accelerate if there are pending callbacks, but the check rather uselessly accelerates only if there are no callbacks. This commit therefore inverts this check. Fixes: 15fecf89e46a ("srcu: Abstract multi-tail callback list handling") Signed-off-by: Neeraj Upadhyay <neeraju(a)codeaurora.org> Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/rcu/tree_plugin.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/rcu/tree_plugin.h +++ b/kernel/rcu/tree_plugin.h @@ -1507,7 +1507,7 @@ static void rcu_prepare_for_idle(void) rdtp->last_accelerate = jiffies; for_each_rcu_flavor(rsp) { rdp = this_cpu_ptr(rsp->rda); - if (rcu_segcblist_pend_cbs(&rdp->cblist)) + if (!rcu_segcblist_pend_cbs(&rdp->cblist)) continue; rnp = rdp->mynode; raw_spin_lock_rcu_node(rnp); /* irqs already disabled. */ Patches currently in stable-queue which might be from neeraju(a)codeaurora.org are queue-4.14/rcu-fix-up-pending-cbs-check-in-rcu_prepare_for_idle.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ima: do not update security.ima if appraisal status is not INTEGRITY_PASS" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ima: do not update security.ima if appraisal status is not INTEGRITY_PASS to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb Mon Sep 17 00:00:00 2001 From: Roberto Sassu <roberto.sassu(a)huawei.com> Date: Tue, 7 Nov 2017 11:37:07 +0100 Subject: ima: do not update security.ima if appraisal status is not INTEGRITY_PASS From: Roberto Sassu <roberto.sassu(a)huawei.com> commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream. Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters") moved the call of ima_file_check() from may_open() to do_filp_open() at a point where the file descriptor is already opened. This breaks the assumption made by IMA that file descriptors being closed belong to files whose access was granted by ima_file_check(). The consequence is that security.ima and security.evm are updated with good values, regardless of the current appraisal status. For example, if a file does not have security.ima, IMA will create it after opening the file for writing, even if access is denied. Access to the file will be allowed afterwards. Avoid this issue by checking the appraisal status before updating security.ima. Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/integrity/ima/ima_appraise.c | 3 +++ 1 file changed, 3 insertions(+) --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -320,6 +320,9 @@ void ima_update_xattr(struct integrity_i if (iint->flags & IMA_DIGSIG) return; + if (iint->ima_file_status != INTEGRITY_PASS) + return; + rc = ima_collect_measurement(iint, file, NULL, 0, ima_hash_algo); if (rc < 0) return; Patches currently in stable-queue which might be from roberto.sassu(a)huawei.com are queue-4.14/ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "tpm-dev-common: Reject too short writes" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tpm-dev-common: Reject too short writes to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tpm-dev-common-reject-too-short-writes.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ee70bc1e7b63ac8023c9ff9475d8741e397316e7 Mon Sep 17 00:00:00 2001 From: Alexander Steffen <Alexander.Steffen(a)infineon.com> Date: Fri, 8 Sep 2017 17:21:32 +0200 Subject: tpm-dev-common: Reject too short writes From: Alexander Steffen <Alexander.Steffen(a)infineon.com> commit ee70bc1e7b63ac8023c9ff9475d8741e397316e7 upstream. tpm_transmit() does not offer an explicit interface to indicate the number of valid bytes in the communication buffer. Instead, it relies on the commandSize field in the TPM header that is encoded within the buffer. Therefore, ensure that a) enough data has been written to the buffer, so that the commandSize field is present and b) the commandSize field does not announce more data than has been written to the buffer. This should have been fixed with CVE-2011-1161 long ago, but apparently a correct version of that patch never made it into the kernel. Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/char/tpm/tpm-dev-common.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/char/tpm/tpm-dev-common.c +++ b/drivers/char/tpm/tpm-dev-common.c @@ -110,6 +110,12 @@ ssize_t tpm_common_write(struct file *fi return -EFAULT; } + if (in_size < 6 || + in_size < be32_to_cpu(*((__be32 *) (priv->data_buffer + 2)))) { + mutex_unlock(&priv->buffer_mutex); + return -EINVAL; + } + /* atomic tpm command send and result receive. We only hold the ops * lock during this period so that the tpm can be unregistered even if * the char dev is held open. Patches currently in stable-queue which might be from Alexander.Steffen(a)infineon.com are queue-4.13/tpm-dev-common-reject-too-short-writes.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: 8250_fintek: Fix finding base_port with activated SuperIO" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: 8250_fintek: Fix finding base_port with activated SuperIO to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-8250_fintek-fix-finding-base_port-with-activated-superio.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd97e66c5529046e989a0879c3bb58fddb592c71 Mon Sep 17 00:00:00 2001 From: "Ji-Ze Hong (Peter Hong)" <hpeter(a)gmail.com> Date: Tue, 17 Oct 2017 14:23:08 +0800 Subject: serial: 8250_fintek: Fix finding base_port with activated SuperIO From: Ji-Ze Hong (Peter Hong) <hpeter(a)gmail.com> commit fd97e66c5529046e989a0879c3bb58fddb592c71 upstream. The SuperIO will be configured at boot time by BIOS, but some BIOS will not deactivate the SuperIO when the end of configuration. It'll lead to mismatch for pdata->base_port in probe_setup_port(). So we'll deactivate all SuperIO before activate special base_port in fintek_8250_enter_key(). Tested on iBASE MI802. Tested-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel(a)gmail.com> Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel(a)gmail.com> Reviewd-by: Alan Cox <alan(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/8250/8250_fintek.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/tty/serial/8250/8250_fintek.c +++ b/drivers/tty/serial/8250/8250_fintek.c @@ -118,6 +118,9 @@ static int fintek_8250_enter_key(u16 bas if (!request_muxed_region(base_port, 2, "8250_fintek")) return -EBUSY; + /* Force to deactive all SuperIO in this base_port */ + outb(EXIT_KEY, base_port + ADDR_PORT); + outb(key, base_port + ADDR_PORT); outb(key, base_port + ADDR_PORT); return 0; Patches currently in stable-queue which might be from hpeter(a)gmail.com are queue-4.13/serial-8250_fintek-fix-finding-base_port-with-activated-superio.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: omap: Fix EFR write on RTS deassertion" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: omap: Fix EFR write on RTS deassertion to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: serial-omap-fix-efr-write-on-rts-deassertion.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2a71de2f7366fb1aec632116d0549ec56d6a3940 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Sat, 21 Oct 2017 10:50:18 +0200 Subject: serial: omap: Fix EFR write on RTS deassertion From: Lukas Wunner <lukas(a)wunner.de> commit 2a71de2f7366fb1aec632116d0549ec56d6a3940 upstream. Commit 348f9bb31c56 ("serial: omap: Fix RTS handling") sought to enable auto RTS upon manual RTS assertion and disable it on deassertion. However it seems the latter was done incorrectly, it clears all bits in the Extended Features Register *except* auto RTS. Fixes: 348f9bb31c56 ("serial: omap: Fix RTS handling") Cc: Peter Hurley <peter(a)hurleysoftware.com> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/omap-serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -693,7 +693,7 @@ static void serial_omap_set_mctrl(struct if ((mctrl & TIOCM_RTS) && (port->status & UPSTAT_AUTORTS)) up->efr |= UART_EFR_RTS; else - up->efr &= UART_EFR_RTS; + up->efr &= ~UART_EFR_RTS; serial_out(up, UART_EFR, up->efr); serial_out(up, UART_LCR, lcr); Patches currently in stable-queue which might be from lukas(a)wunner.de are queue-4.13/serial-omap-fix-efr-write-on-rts-deassertion.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ima: do not update security.ima if appraisal status is not INTEGRITY_PASS" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ima: do not update security.ima if appraisal status is not INTEGRITY_PASS to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb Mon Sep 17 00:00:00 2001 From: Roberto Sassu <roberto.sassu(a)huawei.com> Date: Tue, 7 Nov 2017 11:37:07 +0100 Subject: ima: do not update security.ima if appraisal status is not INTEGRITY_PASS From: Roberto Sassu <roberto.sassu(a)huawei.com> commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream. Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters") moved the call of ima_file_check() from may_open() to do_filp_open() at a point where the file descriptor is already opened. This breaks the assumption made by IMA that file descriptors being closed belong to files whose access was granted by ima_file_check(). The consequence is that security.ima and security.evm are updated with good values, regardless of the current appraisal status. For example, if a file does not have security.ima, IMA will create it after opening the file for writing, even if access is denied. Access to the file will be allowed afterwards. Avoid this issue by checking the appraisal status before updating security.ima. Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/integrity/ima/ima_appraise.c | 3 +++ 1 file changed, 3 insertions(+) --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -320,6 +320,9 @@ void ima_update_xattr(struct integrity_i if (iint->flags & IMA_DIGSIG) return; + if (iint->ima_file_status != INTEGRITY_PASS) + return; + rc = ima_collect_measurement(iint, file, NULL, 0, ima_hash_algo); if (rc < 0) return; Patches currently in stable-queue which might be from roberto.sassu(a)huawei.com are queue-4.13/ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ima: do not update security.ima if appraisal status is not INTEGRITY_PASS" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ima: do not update security.ima if appraisal status is not INTEGRITY_PASS to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb Mon Sep 17 00:00:00 2001 From: Roberto Sassu <roberto.sassu(a)huawei.com> Date: Tue, 7 Nov 2017 11:37:07 +0100 Subject: ima: do not update security.ima if appraisal status is not INTEGRITY_PASS From: Roberto Sassu <roberto.sassu(a)huawei.com> commit 020aae3ee58c1af0e7ffc4e2cc9fe4dc630338cb upstream. Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters") moved the call of ima_file_check() from may_open() to do_filp_open() at a point where the file descriptor is already opened. This breaks the assumption made by IMA that file descriptors being closed belong to files whose access was granted by ima_file_check(). The consequence is that security.ima and security.evm are updated with good values, regardless of the current appraisal status. For example, if a file does not have security.ima, IMA will create it after opening the file for writing, even if access is denied. Access to the file will be allowed afterwards. Avoid this issue by checking the appraisal status before updating security.ima. Signed-off-by: Roberto Sassu <roberto.sassu(a)huawei.com> Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/integrity/ima/ima_appraise.c | 3 +++ 1 file changed, 3 insertions(+) --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -297,6 +297,9 @@ void ima_update_xattr(struct integrity_i if (iint->flags & IMA_DIGSIG) return; + if (iint->ima_file_status != INTEGRITY_PASS) + return; + rc = ima_collect_measurement(iint, file, NULL, NULL); if (rc < 0) return; Patches currently in stable-queue which might be from roberto.sassu(a)huawei.com are queue-3.18/ima-do-not-update-security.ima-if-appraisal-status-is-not-integrity_pass.patch

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 4.4 07/40] arm64: ensure __dump_instr() checks addr_limit

by Ben Hutchings

On Mon, 2017-11-06 at 10:44 +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Mark Rutland <mark.rutland(a)arm.com> > > commit 7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream. > > It's possible for a user to deliberately trigger __dump_instr with a > chosen kernel address. > > Let's avoid problems resulting from this by using get_user() rather than > __get_user(), ensuring that we don't erroneously access kernel memory. > > Where we use __dump_instr() on kernel text, we already switch to > KERNEL_DS, so this shouldn't adversely affect those cases. > > Fixes: 60ffc30d5652810d ("arm64: Exception handling") [...] This seems harmless, but I don't think it will fix the bug in 4.4 unless you also cherry-pick: commit c5cea06be060f38e5400d796e61cfc8c36e52924 Author: Mark Rutland <mark.rutland(a)arm.com> Date: Mon Jun 13 11:15:14 2016 +0100 arm64: fix dump_instr when PAN and UAO are in use Ben. -- Ben Hutchings Software Developer, Codethink Ltd.

7 years, 7 months

4
7
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] tpm_tis_spi: Use DMA-safe memory for SPI transfers" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6b3a13173f23e798e1ba213dd4a2c065a3b8d751 Mon Sep 17 00:00:00 2001 From: Alexander Steffen <Alexander.Steffen(a)infineon.com> Date: Mon, 11 Sep 2017 12:26:52 +0200 Subject: [PATCH] tpm_tis_spi: Use DMA-safe memory for SPI transfers The buffers used as tx_buf/rx_buf in a SPI transfer need to be DMA-safe. This cannot be guaranteed for the buffers passed to tpm_tis_spi_read_bytes and tpm_tis_spi_write_bytes. Therefore, we need to use our own DMA-safe buffer and copy the data to/from it. The buffer needs to be allocated separately, to ensure that it is cacheline-aligned and not shared with other data, so that DMA can work correctly. Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") Cc: stable(a)vger.kernel.org Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c index e49f5b9b739a..8ab0bd8445f6 100644 --- a/drivers/char/tpm/tpm_tis_spi.c +++ b/drivers/char/tpm/tpm_tis_spi.c @@ -46,9 +46,7 @@ struct tpm_tis_spi_phy { struct tpm_tis_data priv; struct spi_device *spi_device; - - u8 tx_buf[4]; - u8 rx_buf[4]; + u8 *iobuf; }; static inline struct tpm_tis_spi_phy *to_tpm_tis_spi_phy(struct tpm_tis_data *data) @@ -71,14 +69,14 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, while (len) { transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE); - phy->tx_buf[0] = (in ? 0x80 : 0) | (transfer_len - 1); - phy->tx_buf[1] = 0xd4; - phy->tx_buf[2] = addr >> 8; - phy->tx_buf[3] = addr; + phy->iobuf[0] = (in ? 0x80 : 0) | (transfer_len - 1); + phy->iobuf[1] = 0xd4; + phy->iobuf[2] = addr >> 8; + phy->iobuf[3] = addr; memset(&spi_xfer, 0, sizeof(spi_xfer)); - spi_xfer.tx_buf = phy->tx_buf; - spi_xfer.rx_buf = phy->rx_buf; + spi_xfer.tx_buf = phy->iobuf; + spi_xfer.rx_buf = phy->iobuf; spi_xfer.len = 4; spi_xfer.cs_change = 1; @@ -88,9 +86,9 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, if (ret < 0) goto exit; - if ((phy->rx_buf[3] & 0x01) == 0) { + if ((phy->iobuf[3] & 0x01) == 0) { // handle SPI wait states - phy->tx_buf[0] = 0; + phy->iobuf[0] = 0; for (i = 0; i < TPM_RETRY; i++) { spi_xfer.len = 1; @@ -99,7 +97,7 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, ret = spi_sync_locked(phy->spi_device, &m); if (ret < 0) goto exit; - if (phy->rx_buf[0] & 0x01) + if (phy->iobuf[0] & 0x01) break; } @@ -112,8 +110,14 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, spi_xfer.cs_change = 0; spi_xfer.len = transfer_len; spi_xfer.delay_usecs = 5; - spi_xfer.tx_buf = out; - spi_xfer.rx_buf = in; + + if (in) { + spi_xfer.tx_buf = NULL; + } else if (out) { + spi_xfer.rx_buf = NULL; + memcpy(phy->iobuf, out, transfer_len); + out += transfer_len; + } spi_message_init(&m); spi_message_add_tail(&spi_xfer, &m); @@ -121,11 +125,12 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, if (ret < 0) goto exit; - len -= transfer_len; - if (in) + if (in) { + memcpy(in, phy->iobuf, transfer_len); in += transfer_len; - if (out) - out += transfer_len; + } + + len -= transfer_len; } exit: @@ -191,6 +196,10 @@ static int tpm_tis_spi_probe(struct spi_device *dev) phy->spi_device = dev; + phy->iobuf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); + if (!phy->iobuf) + return -ENOMEM; + return tpm_tis_core_init(&dev->dev, &phy->priv, -1, &tpm_spi_phy_ops, NULL); }

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] tpm_tis_spi: Use DMA-safe memory for SPI transfers" failed to apply to 4.13-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.13-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 6b3a13173f23e798e1ba213dd4a2c065a3b8d751 Mon Sep 17 00:00:00 2001 From: Alexander Steffen <Alexander.Steffen(a)infineon.com> Date: Mon, 11 Sep 2017 12:26:52 +0200 Subject: [PATCH] tpm_tis_spi: Use DMA-safe memory for SPI transfers The buffers used as tx_buf/rx_buf in a SPI transfer need to be DMA-safe. This cannot be guaranteed for the buffers passed to tpm_tis_spi_read_bytes and tpm_tis_spi_write_bytes. Therefore, we need to use our own DMA-safe buffer and copy the data to/from it. The buffer needs to be allocated separately, to ensure that it is cacheline-aligned and not shared with other data, so that DMA can work correctly. Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") Cc: stable(a)vger.kernel.org Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c index e49f5b9b739a..8ab0bd8445f6 100644 --- a/drivers/char/tpm/tpm_tis_spi.c +++ b/drivers/char/tpm/tpm_tis_spi.c @@ -46,9 +46,7 @@ struct tpm_tis_spi_phy { struct tpm_tis_data priv; struct spi_device *spi_device; - - u8 tx_buf[4]; - u8 rx_buf[4]; + u8 *iobuf; }; static inline struct tpm_tis_spi_phy *to_tpm_tis_spi_phy(struct tpm_tis_data *data) @@ -71,14 +69,14 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, while (len) { transfer_len = min_t(u16, len, MAX_SPI_FRAMESIZE); - phy->tx_buf[0] = (in ? 0x80 : 0) | (transfer_len - 1); - phy->tx_buf[1] = 0xd4; - phy->tx_buf[2] = addr >> 8; - phy->tx_buf[3] = addr; + phy->iobuf[0] = (in ? 0x80 : 0) | (transfer_len - 1); + phy->iobuf[1] = 0xd4; + phy->iobuf[2] = addr >> 8; + phy->iobuf[3] = addr; memset(&spi_xfer, 0, sizeof(spi_xfer)); - spi_xfer.tx_buf = phy->tx_buf; - spi_xfer.rx_buf = phy->rx_buf; + spi_xfer.tx_buf = phy->iobuf; + spi_xfer.rx_buf = phy->iobuf; spi_xfer.len = 4; spi_xfer.cs_change = 1; @@ -88,9 +86,9 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, if (ret < 0) goto exit; - if ((phy->rx_buf[3] & 0x01) == 0) { + if ((phy->iobuf[3] & 0x01) == 0) { // handle SPI wait states - phy->tx_buf[0] = 0; + phy->iobuf[0] = 0; for (i = 0; i < TPM_RETRY; i++) { spi_xfer.len = 1; @@ -99,7 +97,7 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, ret = spi_sync_locked(phy->spi_device, &m); if (ret < 0) goto exit; - if (phy->rx_buf[0] & 0x01) + if (phy->iobuf[0] & 0x01) break; } @@ -112,8 +110,14 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, spi_xfer.cs_change = 0; spi_xfer.len = transfer_len; spi_xfer.delay_usecs = 5; - spi_xfer.tx_buf = out; - spi_xfer.rx_buf = in; + + if (in) { + spi_xfer.tx_buf = NULL; + } else if (out) { + spi_xfer.rx_buf = NULL; + memcpy(phy->iobuf, out, transfer_len); + out += transfer_len; + } spi_message_init(&m); spi_message_add_tail(&spi_xfer, &m); @@ -121,11 +125,12 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u16 len, if (ret < 0) goto exit; - len -= transfer_len; - if (in) + if (in) { + memcpy(in, phy->iobuf, transfer_len); in += transfer_len; - if (out) - out += transfer_len; + } + + len -= transfer_len; } exit: @@ -191,6 +196,10 @@ static int tpm_tis_spi_probe(struct spi_device *dev) phy->spi_device = dev; + phy->iobuf = devm_kmalloc(&dev->dev, MAX_SPI_FRAMESIZE, GFP_KERNEL); + if (!phy->iobuf) + return -ENOMEM; + return tpm_tis_core_init(&dev->dev, &phy->priv, -1, &tpm_spi_phy_ops, NULL); }

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror