<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v5.10.237</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.237</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.10.237'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-05-02T05:41:22+00:00</updated>
<entry>
<title>Linux 5.10.237</title>
<updated>2025-05-02T05:41:22+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2025-05-02T05:41:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=024a4a45fdf87218e3c0925475b05a27bcea103f'/>
<id>urn:sha1:024a4a45fdf87218e3c0925475b05a27bcea103f</id>
<content type='text'>
Link: https://lore.kernel.org/r/20250429161107.848008295@linuxfoundation.org
Tested-by: Pavel Machek (CIP) &lt;pavel@denx.de&gt;
Tested-by: Dominique Martinet &lt;dominique.martinet@atmark-techno.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Linux Kernel Functional Testing &lt;lkft@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: venus: hfi_parser: Check for instance after hfi platform get</title>
<updated>2025-05-02T05:41:22+00:00</updated>
<author>
<name>Stanimir Varbanov</name>
<email>stanimir.varbanov@linaro.org</email>
</author>
<published>2021-03-07T11:17:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ed26013001092a66633436680e225020781810e6'/>
<id>urn:sha1:ed26013001092a66633436680e225020781810e6</id>
<content type='text'>
commit 9b5d8fd580caa898c6e1b8605c774f2517f786ab upstream.

The inst function argument is != NULL only for Venus v1 and
we did not migrate v1 to a hfi_platform abstraction yet. So
check for instance != NULL only after hfi_platform_get returns
no error.

Fixes: e29929266be1 ("media: venus: Get codecs and capabilities from hfi platform")
Cc: stable@vger.kernel.org # v5.12
Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Tested-by: Bryan O'Donoghue &lt;bryan.odonoghue@linaro.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>media: venus: Fix uninitialized variable count being checked for zero</title>
<updated>2025-05-02T05:41:21+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2021-01-15T10:11:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2b524801df52c50c244cf32e1037a68d391f6730'/>
<id>urn:sha1:2b524801df52c50c244cf32e1037a68d391f6730</id>
<content type='text'>
commit c5b14df7a80acadbbd184808dc3f519fbb2ab96c upstream.

In the case where plat-&gt;codecs is NULL the variable count is uninitialized
but is being checked to see if it is 0. Fix this by initializing
count to 0.

Addresses-Coverity: ("Uninitialized scalar variable")

Fixes: e29929266be1 ("media: venus: Get codecs and capabilities from hfi platform")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Stanimir Varbanov &lt;stanimir.varbanov@linaro.org&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>soc: samsung: exynos-chipid: correct helpers __init annotation</title>
<updated>2025-05-02T05:41:21+00:00</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzk@kernel.org</email>
</author>
<published>2021-01-05T17:44:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c0c89fed99caadbf0213380547e0c8913baf08a6'/>
<id>urn:sha1:c0c89fed99caadbf0213380547e0c8913baf08a6</id>
<content type='text'>
commit 6166174afc2bc74ca550af388508384b57d5163d upstream.

After converting to builtin driver, the probe function should not call
__init functions anymore:

  &gt;&gt; WARNING: modpost: vmlinux.o(.text+0x8884d4):
  Section mismatch in reference from the function exynos_chipid_probe() to the function .init.text:product_id_to_soc_id()

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Fixes: 352bfbb3e023 ("soc: samsung: exynos-chipid: convert to driver and merge exynos-asv")
Signed-off-by: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Link: https://lore.kernel.org/r/20210105174440.120041-1-krzk@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>PCI: Fix use-after-free in pci_bus_release_domain_nr()</title>
<updated>2025-05-02T05:41:21+00:00</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2023-03-29T12:38:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=52b0343c7d628f37b38e3279ba585526b850ad3b'/>
<id>urn:sha1:52b0343c7d628f37b38e3279ba585526b850ad3b</id>
<content type='text'>
commit 30ba2d09edb5ea857a1473ae3d820911347ada62 upstream.

Commit c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()")
introduced a use-after-free bug in the bus removal cleanup. The issue was
found with kfence:

  [   19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70

  [   19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115):
  [   19.309677]  pci_bus_release_domain_nr+0x10/0x70
  [   19.309691]  dw_pcie_host_deinit+0x28/0x78
  [   19.309702]  tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]
  [   19.309734]  tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]
  [   19.309752]  platform_probe+0x90/0xd8
  ...

  [   19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k

  [   19.311469] allocated by task 96 on cpu 10 at 19.279323s:
  [   19.311562]  __kmem_cache_alloc_node+0x260/0x278
  [   19.311571]  kmalloc_trace+0x24/0x30
  [   19.311580]  pci_alloc_bus+0x24/0xa0
  [   19.311590]  pci_register_host_bridge+0x48/0x4b8
  [   19.311601]  pci_scan_root_bus_bridge+0xc0/0xe8
  [   19.311613]  pci_host_probe+0x18/0xc0
  [   19.311623]  dw_pcie_host_init+0x2c0/0x568
  [   19.311630]  tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194]
  [   19.311647]  platform_probe+0x90/0xd8
  ...

  [   19.311782] freed by task 96 on cpu 10 at 19.285833s:
  [   19.311799]  release_pcibus_dev+0x30/0x40
  [   19.311808]  device_release+0x30/0x90
  [   19.311814]  kobject_put+0xa8/0x120
  [   19.311832]  device_unregister+0x20/0x30
  [   19.311839]  pci_remove_bus+0x78/0x88
  [   19.311850]  pci_remove_root_bus+0x5c/0x98
  [   19.311860]  dw_pcie_host_deinit+0x28/0x78
  [   19.311866]  tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]
  [   19.311883]  tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]
  [   19.311900]  platform_probe+0x90/0xd8
  ...

  [   19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4
  [   19.320171] Hardware name:  /, BIOS 1.0-d7fb19b 08/10/2022
  [   19.325852] Workqueue: events_unbound deferred_probe_work_func

The stack trace is a bit misleading as dw_pcie_host_deinit() doesn't
directly call pci_bus_release_domain_nr(). The issue turns out to be in
pci_remove_root_bus() which first calls pci_remove_bus() which frees the
struct pci_bus when its struct device is released. Then
pci_bus_release_domain_nr() is called and accesses the freed struct
pci_bus. Reordering these fixes the issue.

Fixes: c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()")
Link: https://lore.kernel.org/r/20230329123835.2724518-1-robh@kernel.org
Link: https://lore.kernel.org/r/b529cb69-0602-9eed-fc02-2f068707a006@nvidia.com
Reported-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Tested-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Kuppuswamy Sathyanarayanan &lt;sathyanarayanan.kuppuswamy@linux.intel.com&gt;
Cc: stable@vger.kernel.org	# v6.2+
Cc: Pali Rohár &lt;pali@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>nvme: fixup scan failure for non-ANA multipath controllers</title>
<updated>2025-05-02T05:41:21+00:00</updated>
<author>
<name>Hannes Reinecke</name>
<email>hare@kernel.org</email>
</author>
<published>2025-04-14T12:05:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a2409be923d5fc517129d43306a99abfdf6e9338'/>
<id>urn:sha1:a2409be923d5fc517129d43306a99abfdf6e9338</id>
<content type='text'>
commit 26d7fb4fd4ca1180e2fa96587dea544563b4962a upstream.

Commit 62baf70c3274 caused the ANA log page to be re-read, even on
controllers that do not support ANA.  While this should generally
harmless, some controllers hang on the unsupported log page and
never finish probing.

Fixes: 62baf70c3274 ("nvme: re-read ANA log page after ns scan completes")
Signed-off-by: Hannes Reinecke &lt;hare@kernel.org&gt;
Tested-by: Srikanth Aithal &lt;sraithal@amd.com&gt;
[hch: more detailed commit message]
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>MIPS: cm: Fix warning if MIPS_CM is disabled</title>
<updated>2025-05-02T05:41:21+00:00</updated>
<author>
<name>Thomas Bogendoerfer</name>
<email>tsbogend@alpha.franken.de</email>
</author>
<published>2025-02-28T14:37:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b744aff9a3aa9d57383e471a10d57e8e6370946f'/>
<id>urn:sha1:b744aff9a3aa9d57383e471a10d57e8e6370946f</id>
<content type='text'>
commit b73c3ccdca95c237750c981054997c71d33e09d7 upstream.

Commit e27fbe16af5c ("MIPS: cm: Detect CM quirks from device tree")
introduced

arch/mips/include/asm/mips-cm.h:119:13: error: ‘mips_cm_update_property’
	defined but not used [-Werror=unused-function]

Fix this by making empty function implementation inline

Fixes: e27fbe16af5c ("MIPS: cm: Detect CM quirks from device tree")
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xdp: Reset bpf_redirect_info before running a xdp's BPF prog.</title>
<updated>2025-05-02T05:41:21+00:00</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2025-04-24T13:04:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a144592d5e9e0a5e0e6d6640c22831b44418f49f'/>
<id>urn:sha1:a144592d5e9e0a5e0e6d6640c22831b44418f49f</id>
<content type='text'>
Ricardo reported a KASAN discovered use after free in v6.6-stable.

The syzbot starts a BPF program via xdp_test_run_batch() which assigns
ri-&gt;tgt_value via dev_hash_map_redirect() and the return code isn't
XDP_REDIRECT it looks like nonsense. So the output in
bpf_warn_invalid_xdp_action() appears once.
Then the TUN driver runs another BPF program (on the same CPU) which
returns XDP_REDIRECT without setting ri-&gt;tgt_value first. It invokes
bpf_trace_printk() to print four characters and obtain the required
return value. This is enough to get xdp_do_redirect() invoked which
then accesses the pointer in tgt_value which might have been already
deallocated.

This problem does not affect upstream because since commit
	401cb7dae8130 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")

the per-CPU variable is referenced via task's task_struct and exists on
the stack during NAPI callback. Therefore it is cleared once before the
first invocation and remains valid within the RCU section of the NAPI
callback.

Instead of performing the huge backport of the commit (plus its fix ups)
here is an alternative version which only resets the variable in
question prior invoking the BPF program.

Acked-by: Toke Høiland-Jørgensen &lt;toke@kernel.org&gt;
Reported-by: Ricardo Cañuelo Navarro &lt;rcn@igalia.com&gt;
Closes: https://lore.kernel.org/all/20250226-20250204-kasan-slab-use-after-free-read-in-dev_map_enqueue__submit-v3-0-360efec441ba@igalia.com/
Fixes: 97f91a7cf04ff ("bpf: add bpf_redirect_map helper routine")
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>crypto: atmel-sha204a - Set hwrng quality to lowest possible</title>
<updated>2025-05-02T05:41:21+00:00</updated>
<author>
<name>Marek Behún</name>
<email>kabel@kernel.org</email>
</author>
<published>2025-04-22T09:57:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3c83be2bb574d1850a03605d45c9ae2e37e52478'/>
<id>urn:sha1:3c83be2bb574d1850a03605d45c9ae2e37e52478</id>
<content type='text'>
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: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marek Behún &lt;kabel@kernel.org&gt;
Acked-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Marek Behún &lt;kabel@kernel.org&gt;
</content>
</entry>
<entry>
<title>comedi: jr3_pci: Fix synchronous deletion of timer</title>
<updated>2025-05-02T05:41:21+00:00</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2025-04-15T12:39:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e529861e64426656fb41bd8fe39d7e7cadad2421'/>
<id>urn:sha1:e529861e64426656fb41bd8fe39d7e7cadad2421</id>
<content type='text'>
commit 44d9b3f584c59a606b521e7274e658d5b866c699 upstream.

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 &lt;stable@kernel.org&gt;
Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Link: https://lore.kernel.org/r/20250415123901.13483-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
