April 2019 - Linux-stable-mirror

Re: [PATCH] inet: update the IP ID generation algorithm to patch 355b98553789b646ed97ad801a619ff898471b92 standards.

by Greg Kroah-Hartman

On Thu, Apr 18, 2019 at 11:01:42PM +0300, Amit Klein wrote: > Patch 355b98553789b646ed97ad801a619ff898471b92 makes net_hash_mix() return > tru 32 bits of entropy. When used in the IP ID generation algorithm, this > has the effect of extending the IP ID generation key from 32 bits to 64 > bits. > However, net_hash_mix() is only used for IP ID generation starting with > kernel version 4.1. Therefore, earlier kernels remain with 32-bit key. > The patch addresses this issue by explicitly extending the key to 64 bits > for kernels v<4.1. Very nice, thanks! One nit, it's easier to reference commits by a shorter sha1 and the text of the commit, than just one long number. So I would rewrite the subject and paragraphs to be something like the following: ------------ Subject: [PATCH] inet: update the IP ID generation algorithm to higher standards. Commit 355b98553789 ("netns: provide pure entropy for net_hash_mix()") makes net_hash_mix() return a true 32 bits of entropy. When used in the IP ID generation algorithm, this has the effect of extending the IP ID generation key from 32 bits to 64 bits. However, net_hash_mix() is only used for IP ID generation starting with kernel version 4.1. Therefore, earlier kernels remain with 32-bit key no matter what the net_hash_mix() return value is. This change addresses the issue by explicitly extending the key to 64 bits for kernels older than 4.1. ------------ Does that look good to you as an accurate representation? If so, I can edit the text of your patch when I queue it up. thanks, greg k-h

5 years, 6 months

1
1
0 0

Re: [tip:x86/urgent] x86/mpx: Fix recursive munmap() corruption

by Dave Hansen

On 4/18/19 11:29 AM, Sasha Levin wrote: > This commit has been processed because it contains a "Fixes:" tag, > fixing commit: 1de4fa14ee25 x86, mpx: Cleanup unused bound tables. > > The bot has tested the following trees: v5.0.8, v4.19.35, v4.14.112, v4.9.169, v4.4.178. > > v5.0.8: Build OK! > v4.19.35: Failed to apply! Possible dependencies: > dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") I probably should have looked more closely at the state of the code before dd2283f2605e. A more correct Fixes: would probably have referred to dd2283f2605e. *It* appears to be the root cause rather than the original MPX code that I called out. The pre-dd2283f2605e code does this: > /* > * Remove the vma's, and unmap the actual pages > */ > detach_vmas_to_be_unmapped(mm, vma, prev, end); > unmap_region(mm, vma, prev, start, end); > > arch_unmap(mm, vma, start, end); > > /* Fix up all other VM information */ > remove_vma_list(mm, vma); But, this is actually safe. arch_unmap() can't see 'vma' in the rbtree because it's been detached, so it can't do anything to 'vma' that might be unsafe for remove_vma_list()'s use of 'vma'. The bug in dd2283f2605e was moving unmap_region() to the after arch_unmap(). I confirmed this by running the reproducer on v4.19.35. It did not trigger anything there, even with a bunch of debugging enabled which detected the issue in 5.0.

5 years, 6 months

2
1
0 0

[4.4] Follow up fixes for 3fe6e52f0626 ("ovl: override creds with the ones from the superblock mounter")

by Taras Kondratiuk

Upstream commit 3fe6e52f0626 ("ovl: override creds with the ones from the superblock mounter") is present in v4.4.156 as 121b09d30d48. But the patch has a few follow up fixes in upstream that also have to be applied to 4.4: d0e13f5bbe4b ("ovl: fix uid/gid when creating over whiteout") in v4.7-rc4 8fc646b44385 ("ovl: fix random return value on mount") in v4.13-rc2 The first patch should fix v4.4.156 regression reported here: https://bugzilla.kernel.org/show_bug.cgi?id=201633. Rest of stable kernels (4.9+) already have these followup fixes.

5 years, 6 months

3
3
0 0

[PATCH] inet: update the IP ID generation algorithm to patch 355b98553789b646ed97ad801a619ff898471b92 standards.

by Amit Klein

Signed-off-by: Amit Klein <aksecurity(a)gmail.com> --- net/ipv4/route.c | 4 +++- net/ipv6/ip6_output.c | 3 +++ 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index ede610a4abc8..446b6d202643 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -488,13 +488,15 @@ EXPORT_SYMBOL(ip_idents_reserve); void __ip_select_ident(struct iphdr *iph, int segs) { static u32 ip_idents_hashrnd __read_mostly; + static u32 ip_idents_hashrnd_extra __read_mostly; u32 hash, id; net_get_random_once(&ip_idents_hashrnd, sizeof(ip_idents_hashrnd)); + net_get_random_once(&ip_idents_hashrnd_extra, sizeof(ip_idents_hashrnd_extra)); hash = jhash_3words((__force u32)iph->daddr, (__force u32)iph->saddr, - iph->protocol, + iph->protocol^ip_idents_hashrnd_extra, ip_idents_hashrnd); id = ip_idents_reserve(hash, segs); iph->id = htons(id); diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 2b69a4b965ed..58e507a79cdd 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -546,12 +546,15 @@ static void ip6_copy_metadata(struct sk_buff *to, struct sk_buff *from) static void ipv6_select_ident(struct frag_hdr *fhdr, struct rt6_info *rt) { static u32 ip6_idents_hashrnd __read_mostly; + static u32 ip6_idents_hashrnd_extra __read_mostly; u32 hash, id; net_get_random_once(&ip6_idents_hashrnd, sizeof(ip6_idents_hashrnd)); + net_get_random_once(&ip6_idents_hashrnd_extra, sizeof(ip6_idents_hashrnd_extra)); hash = __ipv6_addr_jhash(&rt->rt6i_dst.addr, ip6_idents_hashrnd); hash = __ipv6_addr_jhash(&rt->rt6i_src.addr, hash); + hash = jhash_1word(hash,ip6_idents_hashrnd_extra); id = ip_idents_reserve(hash, 1); fhdr->identification = htonl(id); -- 2.17.1

5 years, 6 months

2
1
0 0

[PATCH 4.19.y 1/2] mm: hide incomplete nr_indirectly_reclaimable in /proc/zoneinfo

by Konstantin Khlebnikov

From: Roman Gushchin <guro(a)fb.com> [ commit c29f9010a35604047f96a7e9d6cbabfa36d996d1 from 4.14.y ] Yongqin reported that /proc/zoneinfo format is broken in 4.14 due to commit 7aaf77272358 ("mm: don't show nr_indirectly_reclaimable in /proc/vmstat") Node 0, zone DMA per-node stats nr_inactive_anon 403 nr_active_anon 89123 nr_inactive_file 128887 nr_active_file 47377 nr_unevictable 2053 nr_slab_reclaimable 7510 nr_slab_unreclaimable 10775 nr_isolated_anon 0 nr_isolated_file 0 <...> nr_vmscan_write 0 nr_vmscan_immediate_reclaim 0 nr_dirtied 6022 nr_written 5985 74240 ^^^^^^^^^^ pages free 131656 The problem is caused by the nr_indirectly_reclaimable counter, which is hidden from the /proc/vmstat, but not from the /proc/zoneinfo. Let's fix this inconsistency and hide the counter from /proc/zoneinfo exactly as from /proc/vmstat. BTW, in 4.19+ the counter has been renamed and exported by the commit b29940c1abd7 ("mm: rename and change semantics of nr_indirectly_reclaimable_bytes"), so there is no such a problem anymore. Cc: <stable(a)vger.kernel.org> # 4.19.y Fixes: 7aaf77272358 ("mm: don't show nr_indirectly_reclaimable in /proc/vmstat") Reported-by: Yongqin Liu <yongqin.liu(a)linaro.org> Signed-off-by: Roman Gushchin <guro(a)fb.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> --- mm/vmstat.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/vmstat.c b/mm/vmstat.c index 72ef3936d15d..7b8937cb2876 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1550,6 +1550,10 @@ static void zoneinfo_show_print(struct seq_file *m, pg_data_t *pgdat, if (is_zone_first_populated(pgdat, zone)) { seq_printf(m, "\n per-node stats"); for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++) { + /* Skip hidden vmstat items. */ + if (*vmstat_text[i + NR_VM_ZONE_STAT_ITEMS + + NR_VM_NUMA_STAT_ITEMS] == '\0') + continue; seq_printf(m, "\n %-12s %lu", vmstat_text[i + NR_VM_ZONE_STAT_ITEMS + NR_VM_NUMA_STAT_ITEMS],

5 years, 6 months

3
6
0 0

[PATCH] IB/hfi1: Failed to drain send queue when QP is put into error state

by Kaike Wan

commit 662d66466637862ef955f7f6e78a286d8cf0ebef upstream. When a QP is put into error state, all pending requests in the send work queue should be drained. The following sequence of events could lead to a failure, causing a request to hang: (1) The QP builds a packet and tries to send through SDMA engine. However, PIO engine is still busy. Consequently, this packet is put on the QP's tx list and the QP is put on the PIO waiting list. The field qp->s_flags is set with HFI1_S_WAIT_PIO_DRAIN; (2) The QP is put into error state by the user application and notify_error_qp() is called, which removes the QP from the PIO waiting list and the packet from the QP's tx list. In addition, qp->s_flags is cleared of RVT_S_ANY_WAIT_IO bits, which does not include HFI1_S_WAIT_PIO_DRAIN bit; (3) The hfi1_schdule_send() function is called to drain the QP's send queue. Subsequently, hfi1_do_send() is called. Since the flag bit HFI1_S_WAIT_PIO_DRAIN is set in qp->s_flags, hfi1_send_ok() fails. As a result, hfi1_do_send() bails out without draining any request from the send queue; (4) The PIO engine completes the sending and tries to wake up any QP on its waiting list. But the QP has been removed from the PIO waiting list and therefore is kept in sleep forever. The fix is to clear qp->s_flags of HFI1_S_ANY_WAIT_IO bits in step (2). HFI1_S_ANY_WAIT_IO includes RVT_S_ANY_WAIT_IO and HFI1_S_WAIT_PIO_DRAIN. [ Corrected commit message to match upstream ] Fixes: 2e2ba09e48b7 ("IB/rdmavt, IB/hfi1: Create device dependent s_flags") Cc: <stable(a)vger.kernel.org> # 4.19.x+ Reviewed-by: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Reviewed-by: Alex Estrin <alex.estrin(a)intel.com> Signed-off-by: Kaike Wan <kaike.wan(a)intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> --- drivers/infiniband/hw/hfi1/qp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/hw/hfi1/qp.c b/drivers/infiniband/hw/hfi1/qp.c index 9b1e84a..63c5ba6 100644 --- a/drivers/infiniband/hw/hfi1/qp.c +++ b/drivers/infiniband/hw/hfi1/qp.c @@ -784,7 +784,7 @@ void notify_error_qp(struct rvt_qp *qp) write_seqlock(lock); if (!list_empty(&priv->s_iowait.list) && !(qp->s_flags & RVT_S_BUSY)) { - qp->s_flags &= ~RVT_S_ANY_WAIT_IO; + qp->s_flags &= ~HFI1_S_ANY_WAIT_IO; list_del_init(&priv->s_iowait.list); priv->s_iowait.lock = NULL; rvt_put_qp(qp);

5 years, 6 months

2
1
0 0

[PATCH] crypto: rockchip - update IV buffer to contain the next IV

by Zhang Zhijie

The Kernel Crypto API request output the next IV data to IV buffer for CBC implementation. So the last block data of ciphertext should be copid into assigned IV buffer. Reported-by: Eric Biggers <ebiggers(a)google.com> Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288") Cc: <stable(a)vger.kernel.org> # v4.5+ Signed-off-by: Zhang Zhijie <zhangzj(a)rock-chips.com> diff --git a/drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c b/drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c index 02dac6ae7e53..7564b4c41afc 100644 --- a/drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c +++ b/drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c @@ -250,9 +250,14 @@ static int rk_set_data_start(struct rk_crypto_info *dev) u8 *src_last_blk = page_address(sg_page(dev->sg_src)) + dev->sg_src->offset + dev->sg_src->length - ivsize; - /* store the iv that need to be updated in chain mode */ - if (ctx->mode & RK_CRYPTO_DEC) + /* Store the iv that need to be updated in chain mode. + * And update the IV buffer to contain the next IV for decryption mode. + */ + if (ctx->mode & RK_CRYPTO_DEC) { memcpy(ctx->iv, src_last_blk, ivsize); + sg_pcopy_to_buffer(dev->first, dev->src_nents, req->info, + ivsize, dev->total - ivsize); + } err = dev->load_data(dev, dev->sg_src, dev->sg_dst); if (!err) @@ -288,13 +293,19 @@ static void rk_iv_copyback(struct rk_crypto_info *dev) struct ablkcipher_request *req = ablkcipher_request_cast(dev->async_req); struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(req); + struct rk_cipher_ctx *ctx = crypto_ablkcipher_ctx(tfm); u32 ivsize = crypto_ablkcipher_ivsize(tfm); - if (ivsize == DES_BLOCK_SIZE) - memcpy_fromio(req->info, dev->reg + RK_CRYPTO_TDES_IV_0, - ivsize); - else if (ivsize == AES_BLOCK_SIZE) - memcpy_fromio(req->info, dev->reg + RK_CRYPTO_AES_IV_0, ivsize); + /* Update the IV buffer to contain the next IV for encryption mode. */ + if (!(ctx->mode & RK_CRYPTO_DEC)) { + if (dev->aligned) { + memcpy(req->info, sg_virt(dev->sg_dst) + + dev->sg_dst->length - ivsize, ivsize); + } else { + memcpy(req->info, dev->addr_vir + + dev->count - ivsize, ivsize); + } + } } static void rk_update_iv(struct rk_crypto_info *dev) -- 2.17.1

5 years, 6 months

2
1
0 0

[PATCH] crypto: ccp: Do not free psp_master when PLATFORM_INIT fails

by Singh, Brijesh

Currently, we free the psp_master if the PLATFORM_INIT fails during the SEV FW probe. If psp_master is freed then driver does not invoke the PSP FW. As per SEV FW spec, there are several commands (PLATFORM_RESET, PLATFORM_STATUS, GET_ID etc) which can be executed in the UNINIT state We should not free the psp_master when PLATFORM_INIT fails. Fixes: 200664d5237f ("crypto: ccp: Add SEV support") Cc: Tom Lendacky <thomas.lendacky(a)amd.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: Gary Hook <gary.hook(a)amd.com> Cc: stable(a)vger.kernel.org # 4.19.y Signed-off-by: Brijesh Singh <brijesh.singh(a)amd.com> --- drivers/crypto/ccp/psp-dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto/ccp/psp-dev.c index 80a59be9c80d..656838433f2f 100644 --- a/drivers/crypto/ccp/psp-dev.c +++ b/drivers/crypto/ccp/psp-dev.c @@ -1064,7 +1064,7 @@ void psp_pci_init(void) rc = sev_platform_init(&error); if (rc) { dev_err(sp->dev, "SEV: failed to INIT error %#x\n", error); - goto err; + return; } dev_info(sp->dev, "SEV API:%d.%d build:%d\n", psp_master->api_major, -- 2.17.1

5 years, 6 months

2
1
0 0

[PATCH 35/35] crypto: ccree: handle tee fips error during power management resume

by Gilad Ben-Yossef

From: Ofir Drang <ofir.drang(a)arm.com> in order to support cryptocell tee fips error that may occurs while cryptocell ree is suspended, an cc_tee_handle_fips_error call added to the cc_pm_resume function. Signed-off-by: Ofir Drang <ofir.drang(a)arm.com> Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Cc: stable(a)vger.kernel.org # v4.19+ --- drivers/crypto/ccree/cc_pm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/ccree/cc_pm.c b/drivers/crypto/ccree/cc_pm.c index 77025da2dcb6..2dad9c9543c6 100644 --- a/drivers/crypto/ccree/cc_pm.c +++ b/drivers/crypto/ccree/cc_pm.c @@ -11,6 +11,7 @@ #include "cc_ivgen.h" #include "cc_hash.h" #include "cc_pm.h" +#include "cc_fips.h" #define POWER_DOWN_ENABLE 0x01 #define POWER_DOWN_DISABLE 0x00 @@ -50,12 +51,13 @@ int cc_pm_resume(struct device *dev) } cc_iowrite(drvdata, CC_REG(HOST_POWER_DOWN_EN), POWER_DOWN_DISABLE); - rc = init_cc_regs(drvdata, false); if (rc) { dev_err(dev, "init_cc_regs (%x)\n", rc); return rc; } + /* check if tee fips error occurred during power down */ + cc_tee_handle_fips_error(drvdata); rc = cc_resume_req_queue(drvdata); if (rc) { -- 2.21.0

5 years, 6 months

1
0
0 0

[PATCH 34/35] crypto: ccree: add function to handle cryptocell tee fips error

by Gilad Ben-Yossef

From: Ofir Drang <ofir.drang(a)arm.com> Adds function that checks if cryptocell tee fips error occurred and in such case triggers system error through kernel panic. Change fips function to use this new routine. Signed-off-by: Ofir Drang <ofir.drang(a)arm.com> Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Cc: stable(a)vger.kernel.org # v4.19+ --- drivers/crypto/ccree/cc_fips.c | 23 +++++++++++++++-------- drivers/crypto/ccree/cc_fips.h | 2 ++ 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/ccree/cc_fips.c b/drivers/crypto/ccree/cc_fips.c index 4a67248f5625..5ad3ffb7acaa 100644 --- a/drivers/crypto/ccree/cc_fips.c +++ b/drivers/crypto/ccree/cc_fips.c @@ -70,20 +70,28 @@ static inline void tee_fips_error(struct device *dev) dev_err(dev, "TEE reported error!\n"); } +/* + * This function check if cryptocell tee fips error occurred + * and in such case triggers system error + */ +void cc_tee_handle_fips_error(struct cc_drvdata *p_drvdata) +{ + struct device *dev = drvdata_to_dev(p_drvdata); + + if (!cc_get_tee_fips_status(p_drvdata)) + tee_fips_error(dev); +} + /* Deferred service handler, run as interrupt-fired tasklet */ static void fips_dsr(unsigned long devarg) { struct cc_drvdata *drvdata = (struct cc_drvdata *)devarg; - struct device *dev = drvdata_to_dev(drvdata); - u32 irq, state, val; + u32 irq, val; irq = (drvdata->irq & (CC_GPR0_IRQ_MASK)); if (irq) { - state = cc_ioread(drvdata, CC_REG(GPR_HOST)); - - if (state != (CC_FIPS_SYNC_TEE_STATUS | CC_FIPS_SYNC_MODULE_OK)) - tee_fips_error(dev); + cc_tee_handle_fips_error(drvdata); } /* after verifing that there is nothing to do, @@ -111,8 +119,7 @@ int cc_fips_init(struct cc_drvdata *p_drvdata) dev_dbg(dev, "Initializing fips tasklet\n"); tasklet_init(&fips_h->tasklet, fips_dsr, (unsigned long)p_drvdata); - if (!cc_get_tee_fips_status(p_drvdata)) - tee_fips_error(dev); + cc_tee_handle_fips_error(p_drvdata); return 0; } diff --git a/drivers/crypto/ccree/cc_fips.h b/drivers/crypto/ccree/cc_fips.h index 2c287faf10ff..fc33eeb4d566 100644 --- a/drivers/crypto/ccree/cc_fips.h +++ b/drivers/crypto/ccree/cc_fips.h @@ -18,6 +18,7 @@ int cc_fips_init(struct cc_drvdata *p_drvdata); void cc_fips_fini(struct cc_drvdata *drvdata); void fips_handler(struct cc_drvdata *drvdata); void cc_set_ree_fips_status(struct cc_drvdata *drvdata, bool ok); +void cc_tee_handle_fips_error(struct cc_drvdata *p_drvdata); #else /* CONFIG_CRYPTO_FIPS */ @@ -30,6 +31,7 @@ static inline void cc_fips_fini(struct cc_drvdata *drvdata) {} static inline void cc_set_ree_fips_status(struct cc_drvdata *drvdata, bool ok) {} static inline void fips_handler(struct cc_drvdata *drvdata) {} +static inline void cc_tee_handle_fips_error(struct cc_drvdata *p_drvdata) {} #endif /* CONFIG_CRYPTO_FIPS */ -- 2.21.0

5 years, 6 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2019