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

[PATCH 5.15.y v2] net/sched: act_mirred: don't override retval if we already lost the skb

by jianqi.ren.cn＠windriver.com

From: Jakub Kicinski <kuba(a)kernel.org> [ Upstream commit 166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210 ] If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it. Reviewed-by: Michal Swiatkowski <michal.swiatkowski(a)linux.intel.com> Fixes: e5cf1baf92cb ("act_mirred: use TC_ACT_REINSERT when possible") Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Acked-by: Jamal Hadi Salim <jhs(a)mojatatu.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [Minor conflict resolved due to code context change.] Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- v2: Fix the following issue net/sched/act_mirred.c:265:6: error: variable 'is_redirect' is used uninitialized whenever 'if' condition is true found by the following tuxmake (https://lore.kernel.org/stable/CA+G9fYu+FEZ-3ye30Hk2sk1+LFsw7iO5AHueUa9H1Ub…) Verified the build test by cmd(tuxmake --runtime podman --target-arch arm --toolchain clang-20 --kconfig allmodconfig LLVM=1 LLVM_IAS=1) --- net/sched/act_mirred.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c index 97cd4b2377d6..1aa1d10de30e 100644 --- a/net/sched/act_mirred.c +++ b/net/sched/act_mirred.c @@ -254,31 +254,31 @@ static int tcf_mirred_act(struct sk_buff *skb, const struct tc_action *a, m_mac_header_xmit = READ_ONCE(m->tcfm_mac_header_xmit); m_eaction = READ_ONCE(m->tcfm_eaction); + is_redirect = tcf_mirred_is_act_redirect(m_eaction); retval = READ_ONCE(m->tcf_action); dev = rcu_dereference_bh(m->tcfm_dev); if (unlikely(!dev)) { pr_notice_once("tc mirred: target device is gone\n"); - goto out; + goto err_cant_do; } if (unlikely(!(dev->flags & IFF_UP)) || !netif_carrier_ok(dev)) { net_notice_ratelimited("tc mirred to Houston: device %s is down\n", dev->name); - goto out; + goto err_cant_do; } /* we could easily avoid the clone only if called by ingress and clsact; * since we can't easily detect the clsact caller, skip clone only for * ingress - that covers the TC S/W datapath. */ - is_redirect = tcf_mirred_is_act_redirect(m_eaction); at_ingress = skb_at_tc_ingress(skb); use_reinsert = at_ingress && is_redirect && tcf_mirred_can_reinsert(retval); if (!use_reinsert) { skb2 = skb_clone(skb, GFP_ATOMIC); if (!skb2) - goto out; + goto err_cant_do; } want_ingress = tcf_mirred_act_wants_ingress(m_eaction); @@ -321,12 +321,16 @@ static int tcf_mirred_act(struct sk_buff *skb, const struct tc_action *a, } err = tcf_mirred_forward(want_ingress, skb2); - if (err) { -out: + if (err) tcf_action_inc_overlimit_qstats(&m->common); - if (tcf_mirred_is_act_redirect(m_eaction)) - retval = TC_ACT_SHOT; - } + __this_cpu_dec(mirred_nest_level); + + return retval; + +err_cant_do: + if (is_redirect) + retval = TC_ACT_SHOT; + tcf_action_inc_overlimit_qstats(&m->common); __this_cpu_dec(mirred_nest_level); return retval; -- 2.34.1

2 months

2
1
0 0

platform_shutdown crasher reaches LTS v5.10

by Chuck Lever

Howdy - My queue/5.10 CI test runners have hit this crash on shutdown: [ 42.547410] RIP: 0010:platform_shutdown+0x9/0x20 [ 42.547955] Code: b7 46 08 c3 cc cc cc cc 31 c0 83 bf a8 02 00 00 ff 75 ec c3 cc cc cc cc 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 68 <48> 8b 40 e8 48 85 c0 74 09 48 83 ef 10 e9 35 2c 80 00 c3 cc cc cc [ 42.550016] RSP: 0018:ffffc2ff80013de0 EFLAGS: 00010246 [ 42.550630] RAX: 0000000000000000 RBX: ffff9e6805d2ec18 RCX: 0000000000000000 [ 42.551444] RDX: 0000000000000001 RSI: ffff9e6805d2ec18 RDI: ffff9e6805d2ec10 [ 42.552263] RBP: ffffffff9be79420 R08: ffff9e6805d2f408 R09: ffffffff9bc5c698 [ 42.553081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9e6805d2ec10 [ 42.553900] R13: ffff9e6805d2ec90 R14: 00000000fee1dead R15: 0000000000000000 [ 42.554717] FS: 00007f05a6960b80(0000) GS:ffff9e6b6fc00000(0000) knlGS:0000000000000000 [ 42.555633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.556291] CR2: ffffffffffffffe8 CR3: 000000010960a006 CR4: 0000000000370ef0 [ 42.557105] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 42.557919] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 42.558733] Call Trace: [ 42.559044] device_shutdown+0x15b/0x1c0 [ 42.559512] __do_sys_reboot.cold+0x2f/0x5b [ 42.560015] ? vfs_writev+0x9b/0x110 [ 42.560444] ? do_writev+0x57/0xf0 [ 42.560859] do_syscall_64+0x33/0x40 [ 42.561289] entry_SYSCALL_64_after_hwframe+0x67/0xd1 It's likely due to this recently applied commit: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/… Maybe commit 46e85af0cc53 ("driver core: platform: don't oops in platform_shutdown() on unbound devices") fixes this issue, but I didn't test it. -- Chuck Lever

2 months

2
1
0 0

[lvc-project] [PATCH 5.10/5.15] drm/amd/pm: vega10_hwmgr: fix potential off-by-one overflow in 'performance_levels'

by Igor Artemiev

From: Alexey Kodanev <aleksei.kodanev(a)bell-sw.com> commit 2cc4a5914ce952d6fc83b0f8089a23095ad4f677 upstream. Since 'hardwareActivityPerformanceLevels' is set to the size of the 'performance_levels' array in vega10_hwmgr_backend_init(), using the '<=' assertion to check for the next index value is incorrect. Replace it with '<'. Detected using the static analysis tool - Svace. Fixes: f83a9991648b ("drm/amd/powerplay: add Vega10 powerplay support (v5)") Reviewed-by: Evan Quan <evan.quan(a)amd.com> Signed-off-by: Alexey Kodanev <aleksei.kodanev(a)bell-sw.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> [Igor: In order to adapt this patch to branch 5.10/5.15 the variable name 'vega10_ps' has been changed to 'vega10_power_state' as it is used in branch 5.10/5.15.] Signed-off-by: Igor Artemiev <Igor.A.Artemiev(a)mcst.ru> --- drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c index 79a41180adf1..30eab5002077 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c @@ -3171,7 +3171,7 @@ static int vega10_get_pp_table_entry_callback_func(struct pp_hwmgr *hwmgr, return -1); PP_ASSERT_WITH_CODE( - (vega10_power_state->performance_level_count <= + (vega10_power_state->performance_level_count < hwmgr->platform_descriptor. hardwareActivityPerformanceLevels), "Performance levels exceeds Driver limit!", -- 2.39.2

2 months

1
0
0 0

[PATCH 6.6] iommu: Handle race with default domain setup

by Robin Murphy

[ Upstream commit b46064a18810bad3aea089a79993ca5ea7a3d2b2 ] It turns out that deferred default domain creation leaves a subtle race window during iommu_device_register() wherein a client driver may asynchronously probe in parallel and get as far as performing DMA API operations with dma-direct, only to be switched to iommu-dma underfoot once the default domain attachment finally happens, with obviously disastrous consequences. Even the wonky of_iommu_configure() path is at risk, since iommu_fwspec_init() will no longer defer client probe as the instance ops are (necessarily) already registered, and the "replay" iommu_probe_device() call can see dev->iommu_group already set and so think there's nothing to do either. Fortunately we already have the right tool in the right place in the form of iommu_device_use_default_domain(), which just needs to ensure that said default domain is actually ready to *be* used. Deferring the client probe shouldn't have too much impact, given that this only happens while the IOMMU driver is probing, and thus due to kick the deferred probe list again once it finishes. [ Backport: The above is true for mainline, but here we still have arch_setup_dma_ops() to worry about, which is not replayed if the default domain happens to be allocated *between* that call and subsequently reaching iommu_device_use_default_domain(), so we need an additional earlier check to cover that case. Also we're now back before the nominal commit 98ac73f99bc4 so we need to tweak the logic to depend on IOMMU_DMA as well, to avoid falsely deferring on architectures not using default domains. This then serves us back as far as f188056352bc, where this specific form of the problem first arises. ] Reported-by: Charan Teja Kalla <quic_charante(a)quicinc.com> Fixes: 98ac73f99bc4 ("iommu: Require a default_domain for all iommu drivers") Fixes: f188056352bc ("iommu: Avoid locking/unlocking for iommu_probe_device()") Link: https://lore.kernel.org/r/e88b94c9b575034a2c98a48b3d383654cbda7902.17407532… Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- drivers/iommu/iommu.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 3f1029c0825e..29b48a6a0275 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -566,6 +566,17 @@ int iommu_probe_device(struct device *dev) mutex_lock(&iommu_probe_device_lock); ret = __iommu_probe_device(dev, NULL); mutex_unlock(&iommu_probe_device_lock); + + /* + * The dma_configure replay paths need bus_iommu_probe() to + * finish before they can call arch_setup_dma_ops() + */ + if (IS_ENABLED(CONFIG_IOMMU_DMA) && !ret && dev->iommu_group) { + mutex_lock(&dev->iommu_group->mutex); + if (!dev->iommu_group->default_domain) + ret = -EPROBE_DEFER; + mutex_unlock(&dev->iommu_group->mutex); + } if (ret) return ret; @@ -3149,6 +3160,11 @@ int iommu_device_use_default_domain(struct device *dev) return 0; mutex_lock(&group->mutex); + /* We may race against bus_iommu_probe() finalising groups here */ + if (!group->default_domain) { + ret = -EPROBE_DEFER; + goto unlock_out; + } if (group->owner_cnt) { if (group->owner || !iommu_is_default_domain(group) || !xa_empty(&group->pasid_array)) { -- 2.39.2.101.g768bb238c484.dirty

2 months

3
3
0 0

FAILED: patch "[PATCH] comedi: jr3_pci: Fix synchronous deletion of timer" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 44d9b3f584c59a606b521e7274e658d5b866c699 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025042807-emcee-squealing-c022@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 44d9b3f584c59a606b521e7274e658d5b866c699 Mon Sep 17 00:00:00 2001 From: Ian Abbott <abbotti(a)mev.co.uk> Date: Tue, 15 Apr 2025 13:39:01 +0100 Subject: [PATCH] comedi: jr3_pci: Fix synchronous deletion of timer When `jr3_pci_detach()` is called during device removal, it calls `timer_delete_sync()` to stop the timer, but the timer expiry function always reschedules the timer, so the synchronization is ineffective. Call `timer_shutdown_sync()` instead. It does not matter that the timer expiry function pointer is cleared, because the device is being removed. Fixes: 07b509e6584a5 ("Staging: comedi: add jr3_pci driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Link: https://lore.kernel.org/r/20250415123901.13483-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/comedi/drivers/jr3_pci.c b/drivers/comedi/drivers/jr3_pci.c index cdc842b32bab..75dce1ff2419 100644 --- a/drivers/comedi/drivers/jr3_pci.c +++ b/drivers/comedi/drivers/jr3_pci.c @@ -758,7 +758,7 @@ static void jr3_pci_detach(struct comedi_device *dev) struct jr3_pci_dev_private *devpriv = dev->private; if (devpriv) - timer_delete_sync(&devpriv->timer); + timer_shutdown_sync(&devpriv->timer); comedi_pci_detach(dev); }

2 months

2
1
0 0

[PATCH] drm/v3d: Add job to pending list if the reset was skipped

by Maíra Canal

When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete. However, when `timedout_job()` is called, the job in question is removed from the pending list, which means it won't be automatically freed through `free_job()`. Consequently, when we skip the reset and keep the job running, the job won't be freed when it finally completes. This situation leads to a memory leak, as exposed in [1]. Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout. Cc: stable(a)vger.kernel.org # 6.0 Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12227 [1] Reported-by: Daivik Bhatia <dtgs1208(a)gmail.com> Signed-off-by: Maíra Canal <mcanal(a)igalia.com> --- drivers/gpu/drm/v3d/v3d_sched.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c index b3be08b0ca91..a98dcf9d75b1 100644 --- a/drivers/gpu/drm/v3d/v3d_sched.c +++ b/drivers/gpu/drm/v3d/v3d_sched.c @@ -734,11 +734,6 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job *sched_job) return DRM_GPU_SCHED_STAT_NOMINAL; } -/* If the current address or return address have changed, then the GPU - * has probably made progress and we should delay the reset. This - * could fail if the GPU got in an infinite loop in the CL, but that - * is pretty unlikely outside of an i-g-t testcase. - */ static enum drm_gpu_sched_stat v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q, u32 *timedout_ctca, u32 *timedout_ctra) @@ -748,9 +743,16 @@ v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q, u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(q)); u32 ctra = V3D_CORE_READ(0, V3D_CLE_CTNRA(q)); + /* If the current address or return address have changed, then the GPU + * has probably made progress and we should delay the reset. This + * could fail if the GPU got in an infinite loop in the CL, but that + * is pretty unlikely outside of an i-g-t testcase. + */ if (*timedout_ctca != ctca || *timedout_ctra != ctra) { *timedout_ctca = ctca; *timedout_ctra = ctra; + + list_add(&sched_job->list, &sched_job->sched->pending_list); return DRM_GPU_SCHED_STAT_NOMINAL; } @@ -790,11 +792,13 @@ v3d_csd_job_timedout(struct drm_sched_job *sched_job) struct v3d_dev *v3d = job->base.v3d; u32 batches = V3D_CORE_READ(0, V3D_CSD_CURRENT_CFG4(v3d->ver)); - /* If we've made progress, skip reset and let the timer get - * rearmed. + /* If we've made progress, skip reset, add the job to the pending + * list, and let the timer get rearmed. */ if (job->timedout_batches != batches) { job->timedout_batches = batches; + + list_add(&sched_job->list, &sched_job->sched->pending_list); return DRM_GPU_SCHED_STAT_NOMINAL; } -- 2.49.0

2 months

2
2
0 0

[PATCH 5.4.y] crypto: atmel-sha204a - Set hwrng quality to lowest possible

by Marek Behún

commit 8006aff15516a170640239c5a8e6696c0ba18d8e upstream. According to the review by Bill Cox [1], the Atmel SHA204A random number generator produces random numbers with very low entropy. Set the lowest possible entropy for this chip just to be safe. [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html Fixes: da001fb651b00e1d ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: <stable(a)vger.kernel.org> Signed-off-by: Marek Behún <kabel(a)kernel.org> Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> [ rebased for 5.4 ] Signed-off-by: Marek Behún <kabel(a)kernel.org> --- drivers/crypto/atmel-sha204a.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c index c96c14e7dab1..0ef92109ce22 100644 --- a/drivers/crypto/atmel-sha204a.c +++ b/drivers/crypto/atmel-sha204a.c @@ -107,7 +107,12 @@ static int atmel_sha204a_probe(struct i2c_client *client, i2c_priv->hwrng.name = dev_name(&client->dev); i2c_priv->hwrng.read = atmel_sha204a_rng_read; - i2c_priv->hwrng.quality = 1024; + + /* + * According to review by Bill Cox [1], this HWRNG has very low entropy. + * [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html + */ + i2c_priv->hwrng.quality = 1; ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng); if (ret) -- 2.49.0

2 months

1
0
0 0

[PATCH 5.10.y] crypto: atmel-sha204a - Set hwrng quality to lowest possible

by Marek Behún

commit 8006aff15516a170640239c5a8e6696c0ba18d8e upstream. According to the review by Bill Cox [1], the Atmel SHA204A random number generator produces random numbers with very low entropy. Set the lowest possible entropy for this chip just to be safe. [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html Fixes: da001fb651b00e1d ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: <stable(a)vger.kernel.org> Signed-off-by: Marek Behún <kabel(a)kernel.org> Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> [ rebased for 5.10 ] Signed-off-by: Marek Behún <kabel(a)kernel.org> --- drivers/crypto/atmel-sha204a.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c index c96c14e7dab1..0ef92109ce22 100644 --- a/drivers/crypto/atmel-sha204a.c +++ b/drivers/crypto/atmel-sha204a.c @@ -107,7 +107,12 @@ static int atmel_sha204a_probe(struct i2c_client *client, i2c_priv->hwrng.name = dev_name(&client->dev); i2c_priv->hwrng.read = atmel_sha204a_rng_read; - i2c_priv->hwrng.quality = 1024; + + /* + * According to review by Bill Cox [1], this HWRNG has very low entropy. + * [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html + */ + i2c_priv->hwrng.quality = 1; ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng); if (ret) -- 2.49.0

2 months

1
0
0 0

[PATCH 5.15.y] crypto: atmel-sha204a - Set hwrng quality to lowest possible

by Marek Behún

commit 8006aff15516a170640239c5a8e6696c0ba18d8e upstream. According to the review by Bill Cox [1], the Atmel SHA204A random number generator produces random numbers with very low entropy. Set the lowest possible entropy for this chip just to be safe. [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html Fixes: da001fb651b00e1d ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: <stable(a)vger.kernel.org> Signed-off-by: Marek Behún <kabel(a)kernel.org> Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> [ rebased for 5.15 ] Signed-off-by: Marek Behún <kabel(a)kernel.org> --- drivers/crypto/atmel-sha204a.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c index c96c14e7dab1..0ef92109ce22 100644 --- a/drivers/crypto/atmel-sha204a.c +++ b/drivers/crypto/atmel-sha204a.c @@ -107,7 +107,12 @@ static int atmel_sha204a_probe(struct i2c_client *client, i2c_priv->hwrng.name = dev_name(&client->dev); i2c_priv->hwrng.read = atmel_sha204a_rng_read; - i2c_priv->hwrng.quality = 1024; + + /* + * According to review by Bill Cox [1], this HWRNG has very low entropy. + * [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html + */ + i2c_priv->hwrng.quality = 1; ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng); if (ret) -- 2.49.0

2 months

1
0
0 0

[PATCH 6.1.y] crypto: atmel-sha204a - Set hwrng quality to lowest possible

by Marek Behún

commit 8006aff15516a170640239c5a8e6696c0ba18d8e upstream. According to the review by Bill Cox [1], the Atmel SHA204A random number generator produces random numbers with very low entropy. Set the lowest possible entropy for this chip just to be safe. [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html Fixes: da001fb651b00e1d ("crypto: atmel-i2c - add support for SHA204A random number generator") Cc: <stable(a)vger.kernel.org> Signed-off-by: Marek Behún <kabel(a)kernel.org> Acked-by: Ard Biesheuvel <ardb(a)kernel.org> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> [ rebased for 6.1 ] Signed-off-by: Marek Behún <kabel(a)kernel.org> --- drivers/crypto/atmel-sha204a.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/atmel-sha204a.c b/drivers/crypto/atmel-sha204a.c index a84b657598c6..51738c730717 100644 --- a/drivers/crypto/atmel-sha204a.c +++ b/drivers/crypto/atmel-sha204a.c @@ -107,7 +107,12 @@ static int atmel_sha204a_probe(struct i2c_client *client, i2c_priv->hwrng.name = dev_name(&client->dev); i2c_priv->hwrng.read = atmel_sha204a_rng_read; - i2c_priv->hwrng.quality = 1024; + + /* + * According to review by Bill Cox [1], this HWRNG has very low entropy. + * [1] https://www.metzdowd.com/pipermail/cryptography/2014-December/023858.html + */ + i2c_priv->hwrng.quality = 1; ret = devm_hwrng_register(&client->dev, &i2c_priv->hwrng); if (ret) -- 2.49.0

2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror