kernel/linux.git, branch v5.4.269

Linux 5.4.269

2024-02-23T07:25:15+00:00

Link: https://lore.kernel.org/r/20240221125940.058369148@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: kernelci.org bot Tested-by: Harshit Mogalapalli Signed-off-by: Greg Kroah-Hartman

of: gpio unittest kfree() wrong object

2024-02-23T07:25:15+00:00

commit fb227f597d612c6660888d1947e68a25fed7b9cc upstream. kernel test robot reported "WARNING: held lock freed!" triggered by unittest_gpio_remove(). unittest_gpio_remove() was unexpectedly called due to an error in overlay tracking. The remove had not been tested because the gpio overlay removal tests have not been implemented. kfree() gdev instead of pdev. Fixes: f4056e705b2e ("of: unittest: add overlay gpio test to catch gpio hog problem") Reported-by: kernel test robot Signed-off-by: Frank Rowand Reviewed-by: Geert Uytterhoeven Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

of: unittest: fix EXPECT text for gpio hog errors

2024-02-23T07:25:15+00:00

commit e85860e5bc077865a04f0a88d0b0335d3200484a upstream. The console message text for gpio hog errors does not match what unittest expects. Fixes: f4056e705b2ef ("of: unittest: add overlay gpio test to catch gpio hog problem") Signed-off-by: Frank Rowand Link: https://lore.kernel.org/r/20211029013225.2048695-1-frowand.list@gmail.com Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

net: bcmgenet: Fix EEE implementation

2024-02-23T07:25:15+00:00

commit a9f31047baca57d47440c879cf259b86f900260c upstream. We had a number of short comings: - EEE must be re-evaluated whenever the state machine detects a link change as wight be switching from a link partner with EEE enabled/disabled - tx_lpi_enabled controls whether EEE should be enabled/disabled for the transmit path, which applies to the TBUF block - We do not need to forcibly enable EEE upon system resume, as the PHY state machine will trigger a link event that will do that, too Fixes: 6ef398ea60d9 ("net: bcmgenet: add EEE support") Signed-off-by: Florian Fainelli Reviewed-by: Russell King (Oracle) Link: https://lore.kernel.org/r/20230606214348.2408018-1-florian.fainelli@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

Revert "Revert "mtd: rawnand: gpmi: Fix setting busy timeout setting""

2024-02-23T07:25:15+00:00

This reverts commit 15a3adfe75937c9e4e0e48f0ed40dd39a0e526e2. The backport of [1] relies on having [2] also backported. Having only one of the two results in a bogus hw->timing1 setting. If only [2] is backportet the 16 bit register value likely underflows resulting in a busy_wait_timeout of 0. Or if only [1] is applied the value likely overflows with chances of having last 16 LSBs all 0 which would then result in a busy_wait_timeout of 0 too. Both cases may lead to NAND data corruption, e.g. on a Colibri iMX7 setup this has been seen. [1] commit 0fddf9ad06fd ("mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times") [2] commit 06781a5026350 ("mtd: rawnand: gpmi: Fix setting busy timeout setting") Signed-off-by: Max Krummenacher Signed-off-by: Greg Kroah-Hartman

netfilter: nf_tables: fix pointer math issue in nft_byteorder_eval()

2024-02-23T07:25:15+00:00

commit c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 upstream. The problem is in nft_byteorder_eval() where we are iterating through a loop and writing to dst[0], dst[1], dst[2] and so on... On each iteration we are writing 8 bytes. But dst[] is an array of u32 so each element only has space for 4 bytes. That means that every iteration overwrites part of the previous element. I spotted this bug while reviewing commit caf3ef7468f7 ("netfilter: nf_tables: prevent OOB access in nft_byteorder_eval") which is a related issue. I think that the reason we have not detected this bug in testing is that most of time we only write one element. Fixes: ce1e7989d989 ("netfilter: nft_byteorder: provide 64bit le/be conversion") Signed-off-by: Dan Carpenter Signed-off-by: Pablo Neira Ayuso [Ajay: Modified to apply on v5.4.y] Signed-off-by: Ajay Kaher Signed-off-by: Greg Kroah-Hartman

lsm: new security_file_ioctl_compat() hook

2024-02-23T07:25:15+00:00

commit f1bb47a31dff6d4b34fb14e99850860ee74bb003 upstream. Some ioctl commands do not require ioctl permission, but are routed to other permissions such as FILE_GETATTR or FILE_SETATTR. This routing is done by comparing the ioctl cmd to a set of 64-bit flags (FS_IOC_*). However, if a 32-bit process is running on a 64-bit kernel, it emits 32-bit flags (FS_IOC32_*) for certain ioctl operations. These flags are being checked erroneously, which leads to these ioctl operations being routed to the ioctl permission, rather than the correct file permissions. This was also noted in a RED-PEN finding from a while back - "/* RED-PEN how should LSM module know it's handling 32bit? */". This patch introduces a new hook, security_file_ioctl_compat(), that is called from the compat ioctl syscall. All current LSMs have been changed to support this hook. Reviewing the three places where we are currently using security_file_ioctl(), it appears that only SELinux needs a dedicated compat change; TOMOYO and SMACK appear to be functional without any change. Cc: stable@vger.kernel.org Fixes: 0b24dcb7f2f7 ("Revert "selinux: simplify ioctl checking"") Signed-off-by: Alfred Piccioni Reviewed-by: Stephen Smalley [PM: subject tweak, line length fixes, and alignment corrections] Signed-off-by: Paul Moore Signed-off-by: Eric Biggers Signed-off-by: Greg Kroah-Hartman

drm/msm/dsi: Enable runtime PM

2024-02-23T07:25:14+00:00

[ Upstream commit 6ab502bc1cf3147ea1d8540d04b83a7a4cb6d1f1 ] Some devices power the DSI PHY/PLL through a power rail that we model as a GENPD. Enable runtime PM to make it suspendable. Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/543352/ Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-2-a11a751f34f0@linaro.org Signed-off-by: Dmitry Baryshkov Stable-dep-of: 3d07a411b4fa ("drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks") Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

PM: runtime: Have devm_pm_runtime_enable() handle pm_runtime_dont_use_autosuspend()

2024-02-23T07:25:14+00:00

[ Upstream commit b4060db9251f919506e4d672737c6b8ab9a84701 ] The PM Runtime docs say: Drivers in ->remove() callback should undo the runtime PM changes done in ->probe(). Usually this means calling pm_runtime_disable(), pm_runtime_dont_use_autosuspend() etc. >From grepping code, it's clear that many people aren't aware of the need to call pm_runtime_dont_use_autosuspend(). When brainstorming solutions, one idea that came up was to leverage the new-ish devm_pm_runtime_enable() function. The idea here is that: * When the devm action is called we know that the driver is being removed. It's the perfect time to undo the use_autosuspend. * The code of pm_runtime_dont_use_autosuspend() already handles the case of being called when autosuspend wasn't enabled. Suggested-by: Laurent Pinchart Signed-off-by: Douglas Anderson Reviewed-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Stable-dep-of: 3d07a411b4fa ("drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks") Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman

PM: runtime: add devm_pm_runtime_enable helper

2024-02-23T07:25:14+00:00

[ Upstream commit b3636a3a2c51715736d3ec45f635ed03191962ce ] A typical code pattern for pm_runtime_enable() call is to call it in the _probe function and to call pm_runtime_disable() both from _probe error path and from _remove function. For some drivers the whole remove function would consist of the call to pm_remove_disable(). Add helper function to replace this bolierplate piece of code. Calling devm_pm_runtime_enable() removes the need for calling pm_runtime_disable() both in the probe()'s error path and in the remove() function. Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210731195034.979084-2-dmitry.baryshkov@linaro.org Acked-by: Rafael J. Wysocki Signed-off-by: Stephen Boyd Stable-dep-of: 3d07a411b4fa ("drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks") Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman