From 34df39137952b45011a11d79555bc66474e1ade8 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 18 Oct 2024 09:46:32 +0200 Subject: [PATCH] 5.15-stable patches added patches: arm64-probes-fix-simulate_ldr-_literal.patch arm64-probes-remove-broken-ldr-literal-uprobe-support.patch irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch net-enetc-add-missing-static-descriptor-and-inline-keyword.patch net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch --- ...m64-probes-fix-simulate_ldr-_literal.patch | 79 ++++++++++++ ...ve-broken-ldr-literal-uprobe-support.patch | 121 ++++++++++++++++++ ...erencing-an-unmapped-vpe-on-gic-v4.1.patch | 65 ++++++++++ ...static-descriptor-and-inline-keyword.patch | 47 +++++++ ..._drops-statistic-from-enetc_xdp_drop.patch | 47 +++++++ ...-bus-registration-for-fixed-link-phy.patch | 81 ++++++++++++ ...timespec64-check-in-pc_clock_settime.patch | 52 ++++++++ queue-5.15/series | 7 + 8 files changed, 499 insertions(+) create mode 100644 queue-5.15/arm64-probes-fix-simulate_ldr-_literal.patch create mode 100644 queue-5.15/arm64-probes-remove-broken-ldr-literal-uprobe-support.patch create mode 100644 queue-5.15/irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch create mode 100644 queue-5.15/net-enetc-add-missing-static-descriptor-and-inline-keyword.patch create mode 100644 queue-5.15/net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch create mode 100644 queue-5.15/net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch create mode 100644 queue-5.15/posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch diff --git a/queue-5.15/arm64-probes-fix-simulate_ldr-_literal.patch b/queue-5.15/arm64-probes-fix-simulate_ldr-_literal.patch new file mode 100644 index 00000000000..16c997865ed --- /dev/null +++ b/queue-5.15/arm64-probes-fix-simulate_ldr-_literal.patch @@ -0,0 +1,79 @@ +From 50f813e57601c22b6f26ced3193b9b94d70a2640 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Tue, 8 Oct 2024 16:58:47 +0100 +Subject: arm64: probes: Fix simulate_ldr*_literal() + +From: Mark Rutland + +commit 50f813e57601c22b6f26ced3193b9b94d70a2640 upstream. + +The simulate_ldr_literal() code always loads a 64-bit quantity, and when +simulating a 32-bit load into a 'W' register, it discards the most +significant 32 bits. For big-endian kernels this means that the relevant +bits are discarded, and the value returned is the the subsequent 32 bits +in memory (i.e. the value at addr + 4). + +Additionally, simulate_ldr_literal() and simulate_ldrsw_literal() use a +plain C load, which the compiler may tear or elide (e.g. if the target +is the zero register). Today this doesn't happen to matter, but it may +matter in future if trampoline code uses a LDR (literal) or LDRSW +(literal). + +Update simulate_ldr_literal() and simulate_ldrsw_literal() to use an +appropriately-sized READ_ONCE() to perform the access, which avoids +these problems. + +Fixes: 39a67d49ba35 ("arm64: kprobes instruction simulation support") +Cc: stable@vger.kernel.org +Signed-off-by: Mark Rutland +Cc: Catalin Marinas +Cc: Will Deacon +Link: https://lore.kernel.org/r/20241008155851.801546-3-mark.rutland@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/probes/simulate-insn.c | 18 +++++++----------- + 1 file changed, 7 insertions(+), 11 deletions(-) + +--- a/arch/arm64/kernel/probes/simulate-insn.c ++++ b/arch/arm64/kernel/probes/simulate-insn.c +@@ -171,17 +171,15 @@ simulate_tbz_tbnz(u32 opcode, long addr, + void __kprobes + simulate_ldr_literal(u32 opcode, long addr, struct pt_regs *regs) + { +- u64 *load_addr; ++ unsigned long load_addr; + int xn = opcode & 0x1f; +- int disp; + +- disp = ldr_displacement(opcode); +- load_addr = (u64 *) (addr + disp); ++ load_addr = addr + ldr_displacement(opcode); + + if (opcode & (1 << 30)) /* x0-x30 */ +- set_x_reg(regs, xn, *load_addr); ++ set_x_reg(regs, xn, READ_ONCE(*(u64 *)load_addr)); + else /* w0-w30 */ +- set_w_reg(regs, xn, *load_addr); ++ set_w_reg(regs, xn, READ_ONCE(*(u32 *)load_addr)); + + instruction_pointer_set(regs, instruction_pointer(regs) + 4); + } +@@ -189,14 +187,12 @@ simulate_ldr_literal(u32 opcode, long ad + void __kprobes + simulate_ldrsw_literal(u32 opcode, long addr, struct pt_regs *regs) + { +- s32 *load_addr; ++ unsigned long load_addr; + int xn = opcode & 0x1f; +- int disp; + +- disp = ldr_displacement(opcode); +- load_addr = (s32 *) (addr + disp); ++ load_addr = addr + ldr_displacement(opcode); + +- set_x_reg(regs, xn, *load_addr); ++ set_x_reg(regs, xn, READ_ONCE(*(s32 *)load_addr)); + + instruction_pointer_set(regs, instruction_pointer(regs) + 4); + } diff --git a/queue-5.15/arm64-probes-remove-broken-ldr-literal-uprobe-support.patch b/queue-5.15/arm64-probes-remove-broken-ldr-literal-uprobe-support.patch new file mode 100644 index 00000000000..eb3ae6f314c --- /dev/null +++ b/queue-5.15/arm64-probes-remove-broken-ldr-literal-uprobe-support.patch @@ -0,0 +1,121 @@ +From acc450aa07099d071b18174c22a1119c57da8227 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Tue, 8 Oct 2024 16:58:46 +0100 +Subject: arm64: probes: Remove broken LDR (literal) uprobe support + +From: Mark Rutland + +commit acc450aa07099d071b18174c22a1119c57da8227 upstream. + +The simulate_ldr_literal() and simulate_ldrsw_literal() functions are +unsafe to use for uprobes. Both functions were originally written for +use with kprobes, and access memory with plain C accesses. When uprobes +was added, these were reused unmodified even though they cannot safely +access user memory. + +There are three key problems: + +1) The plain C accesses do not have corresponding extable entries, and + thus if they encounter a fault the kernel will treat these as + unintentional accesses to user memory, resulting in a BUG() which + will kill the kernel thread, and likely lead to further issues (e.g. + lockup or panic()). + +2) The plain C accesses are subject to HW PAN and SW PAN, and so when + either is in use, any attempt to simulate an access to user memory + will fault. Thus neither simulate_ldr_literal() nor + simulate_ldrsw_literal() can do anything useful when simulating a + user instruction on any system with HW PAN or SW PAN. + +3) The plain C accesses are privileged, as they run in kernel context, + and in practice can access a small range of kernel virtual addresses. + The instructions they simulate have a range of +/-1MiB, and since the + simulated instructions must itself be a user instructions in the + TTBR0 address range, these can address the final 1MiB of the TTBR1 + acddress range by wrapping downwards from an address in the first + 1MiB of the TTBR0 address range. + + In contemporary kernels the last 8MiB of TTBR1 address range is + reserved, and accesses to this will always fault, meaning this is no + worse than (1). + + Historically, it was theoretically possible for the linear map or + vmemmap to spill into the final 8MiB of the TTBR1 address range, but + in practice this is extremely unlikely to occur as this would + require either: + + * Having enough physical memory to fill the entire linear map all the + way to the final 1MiB of the TTBR1 address range. + + * Getting unlucky with KASLR randomization of the linear map such + that the populated region happens to overlap with the last 1MiB of + the TTBR address range. + + ... and in either case if we were to spill into the final page there + would be larger problems as the final page would alias with error + pointers. + +Practically speaking, (1) and (2) are the big issues. Given there have +been no reports of problems since the broken code was introduced, it +appears that no-one is relying on probing these instructions with +uprobes. + +Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW +(literal), limiting the use of simulate_ldr_literal() and +simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR +(literal) and LDRSW (literal) will be rejected as +arm_probe_decode_insn() will return INSN_REJECTED. In future we can +consider introducing working uprobes support for these instructions, but +this will require more significant work. + +Fixes: 9842ceae9fa8 ("arm64: Add uprobe support") +Cc: stable@vger.kernel.org +Signed-off-by: Mark Rutland +Cc: Catalin Marinas +Cc: Will Deacon +Link: https://lore.kernel.org/r/20241008155851.801546-2-mark.rutland@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/probes/decode-insn.c | 16 +++++++++++----- + 1 file changed, 11 insertions(+), 5 deletions(-) + +--- a/arch/arm64/kernel/probes/decode-insn.c ++++ b/arch/arm64/kernel/probes/decode-insn.c +@@ -99,10 +99,6 @@ arm_probe_decode_insn(probe_opcode_t ins + aarch64_insn_is_blr(insn) || + aarch64_insn_is_ret(insn)) { + api->handler = simulate_br_blr_ret; +- } else if (aarch64_insn_is_ldr_lit(insn)) { +- api->handler = simulate_ldr_literal; +- } else if (aarch64_insn_is_ldrsw_lit(insn)) { +- api->handler = simulate_ldrsw_literal; + } else { + /* + * Instruction cannot be stepped out-of-line and we don't +@@ -140,6 +136,17 @@ arm_kprobe_decode_insn(kprobe_opcode_t * + probe_opcode_t insn = le32_to_cpu(*addr); + probe_opcode_t *scan_end = NULL; + unsigned long size = 0, offset = 0; ++ struct arch_probe_insn *api = &asi->api; ++ ++ if (aarch64_insn_is_ldr_lit(insn)) { ++ api->handler = simulate_ldr_literal; ++ decoded = INSN_GOOD_NO_SLOT; ++ } else if (aarch64_insn_is_ldrsw_lit(insn)) { ++ api->handler = simulate_ldrsw_literal; ++ decoded = INSN_GOOD_NO_SLOT; ++ } else { ++ decoded = arm_probe_decode_insn(insn, &asi->api); ++ } + + /* + * If there's a symbol defined in front of and near enough to +@@ -157,7 +164,6 @@ arm_kprobe_decode_insn(kprobe_opcode_t * + else + scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE; + } +- decoded = arm_probe_decode_insn(insn, &asi->api); + + if (decoded != INSN_REJECTED && scan_end) + if (is_probed_address_atomic(addr - 1, scan_end)) diff --git a/queue-5.15/irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch b/queue-5.15/irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch new file mode 100644 index 00000000000..d8a47e55052 --- /dev/null +++ b/queue-5.15/irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch @@ -0,0 +1,65 @@ +From 80e9963fb3b5509dfcabe9652d56bf4b35542055 Mon Sep 17 00:00:00 2001 +From: Nianyao Tang +Date: Sat, 6 Apr 2024 02:27:37 +0000 +Subject: irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1 + +From: Nianyao Tang + +commit 80e9963fb3b5509dfcabe9652d56bf4b35542055 upstream. + +As per the GICv4.1 spec (Arm IHI 0069H, 5.3.19): + + "A VMAPP with {V, Alloc}=={0, x} is self-synchronizing, This means the ITS + command queue does not show the command as consumed until all of its + effects are completed." + +Furthermore, VSYNC is allowed to deliver an SError when referencing a +non existent VPE. + +By these definitions, a VMAPP followed by a VSYNC is a bug, as the +later references a VPE that has been unmapped by the former. + +Fix it by eliding the VSYNC in this scenario. + +Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP") +Signed-off-by: Nianyao Tang +Signed-off-by: Thomas Gleixner +Reviewed-by: Marc Zyngier +Reviewed-by: Zenghui Yu +Link: https://lore.kernel.org/r/20240406022737.3898763-1-tangnianyao@huawei.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-gic-v3-its.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/irqchip/irq-gic-v3-its.c ++++ b/drivers/irqchip/irq-gic-v3-its.c +@@ -779,6 +779,7 @@ static struct its_vpe *its_build_vmapp_c + struct its_cmd_block *cmd, + struct its_cmd_desc *desc) + { ++ struct its_vpe *vpe = valid_vpe(its, desc->its_vmapp_cmd.vpe); + unsigned long vpt_addr, vconf_addr; + u64 target; + bool alloc; +@@ -791,6 +792,11 @@ static struct its_vpe *its_build_vmapp_c + if (is_v4_1(its)) { + alloc = !atomic_dec_return(&desc->its_vmapp_cmd.vpe->vmapp_count); + its_encode_alloc(cmd, alloc); ++ /* ++ * Unmapping a VPE is self-synchronizing on GICv4.1, ++ * no need to issue a VSYNC. ++ */ ++ vpe = NULL; + } + + goto out; +@@ -825,7 +831,7 @@ static struct its_vpe *its_build_vmapp_c + out: + its_fixup_cmd(cmd); + +- return valid_vpe(its, desc->its_vmapp_cmd.vpe); ++ return vpe; + } + + static struct its_vpe *its_build_vmapti_cmd(struct its_node *its, diff --git a/queue-5.15/net-enetc-add-missing-static-descriptor-and-inline-keyword.patch b/queue-5.15/net-enetc-add-missing-static-descriptor-and-inline-keyword.patch new file mode 100644 index 00000000000..ee1760d1228 --- /dev/null +++ b/queue-5.15/net-enetc-add-missing-static-descriptor-and-inline-keyword.patch @@ -0,0 +1,47 @@ +From 1d7b2ce43d2c22a21dadaf689cb36a69570346a6 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Fri, 11 Oct 2024 11:01:03 +0800 +Subject: net: enetc: add missing static descriptor and inline keyword + +From: Wei Fang + +commit 1d7b2ce43d2c22a21dadaf689cb36a69570346a6 upstream. + +Fix the build warnings when CONFIG_FSL_ENETC_MDIO is not enabled. +The detailed warnings are shown as follows. + +include/linux/fsl/enetc_mdio.h:62:18: warning: no previous prototype for function 'enetc_hw_alloc' [-Wmissing-prototypes] + 62 | struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs) + | ^ +include/linux/fsl/enetc_mdio.h:62:1: note: declare 'static' if the function is not intended to be used outside of this translation unit + 62 | struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs) + | ^ + | static +8 warnings generated. + +Fixes: 6517798dd343 ("enetc: Make MDIO accessors more generic and export to include/linux/fsl") +Cc: stable@vger.kernel.org +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202410102136.jQHZOcS4-lkp@intel.com/ +Signed-off-by: Wei Fang +Reviewed-by: Claudiu Manoil +Reviewed-by: Vladimir Oltean +Link: https://patch.msgid.link/20241011030103.392362-1-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/fsl/enetc_mdio.h | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/include/linux/fsl/enetc_mdio.h ++++ b/include/linux/fsl/enetc_mdio.h +@@ -48,7 +48,8 @@ static inline int enetc_mdio_read(struct + static inline int enetc_mdio_write(struct mii_bus *bus, int phy_id, int regnum, + u16 value) + { return -EINVAL; } +-struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs) ++static inline struct enetc_hw *enetc_hw_alloc(struct device *dev, ++ void __iomem *port_regs) + { return ERR_PTR(-EINVAL); } + + #endif diff --git a/queue-5.15/net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch b/queue-5.15/net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch new file mode 100644 index 00000000000..c8f1f7dc740 --- /dev/null +++ b/queue-5.15/net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch @@ -0,0 +1,47 @@ +From 412950d5746f7aa139e14fe95338694c1f09b595 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Thu, 10 Oct 2024 17:20:53 +0800 +Subject: net: enetc: remove xdp_drops statistic from enetc_xdp_drop() + +From: Wei Fang + +commit 412950d5746f7aa139e14fe95338694c1f09b595 upstream. + +The xdp_drops statistic indicates the number of XDP frames dropped in +the Rx direction. However, enetc_xdp_drop() is also used in XDP_TX and +XDP_REDIRECT actions. If frame loss occurs in these two actions, the +frames loss count should not be included in xdp_drops, because there +are already xdp_tx_drops and xdp_redirect_failures to count the frame +loss of these two actions, so it's better to remove xdp_drops statistic +from enetc_xdp_drop() and increase xdp_drops in XDP_DROP action. + +Fixes: 7ed2bc80074e ("net: enetc: add support for XDP_TX") +Cc: stable@vger.kernel.org +Signed-off-by: Wei Fang +Reviewed-by: Maciej Fijalkowski +Reviewed-by: Vladimir Oltean +Link: https://patch.msgid.link/20241010092056.298128-2-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -1223,7 +1223,6 @@ static void enetc_xdp_drop(struct enetc_ + &rx_ring->rx_swbd[rx_ring_first]); + enetc_bdr_idx_inc(rx_ring, &rx_ring_first); + } +- rx_ring->stats.xdp_drops++; + } + + static int enetc_clean_rx_ring_xdp(struct enetc_bdr *rx_ring, +@@ -1280,6 +1279,7 @@ static int enetc_clean_rx_ring_xdp(struc + fallthrough; + case XDP_DROP: + enetc_xdp_drop(rx_ring, orig_i, i); ++ rx_ring->stats.xdp_drops++; + break; + case XDP_PASS: + rxbd = orig_rxbd; diff --git a/queue-5.15/net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch b/queue-5.15/net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch new file mode 100644 index 00000000000..bebafae92a5 --- /dev/null +++ b/queue-5.15/net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch @@ -0,0 +1,81 @@ +From d0c3601f2c4e12e7689b0f46ebc17525250ea8c3 Mon Sep 17 00:00:00 2001 +From: Oleksij Rempel +Date: Sun, 13 Oct 2024 07:29:16 +0200 +Subject: net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-link PHY + +From: Oleksij Rempel + +commit d0c3601f2c4e12e7689b0f46ebc17525250ea8c3 upstream. + +A boot delay was introduced by commit 79540d133ed6 ("net: macb: Fix +handling of fixed-link node"). This delay was caused by the call to +`mdiobus_register()` in cases where a fixed-link PHY was present. The +MDIO bus registration triggered unnecessary PHY address scans, leading +to a 20-second delay due to attempts to detect Clause 45 (C45) +compatible PHYs, despite no MDIO bus being attached. + +The commit 79540d133ed6 ("net: macb: Fix handling of fixed-link node") +was originally introduced to fix a regression caused by commit +7897b071ac3b4 ("net: macb: convert to phylink"), which caused the driver +to misinterpret fixed-link nodes as PHY nodes. This resulted in warnings +like: +mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address +mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0 +... +mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31 + +This patch reworks the logic to avoid registering and allocation of the +MDIO bus when: + - The device tree contains a fixed-link node. + - There is no "mdio" child node in the device tree. + +If a child node named "mdio" exists, the MDIO bus will be registered to +support PHYs attached to the MACB's MDIO bus. Otherwise, with only a +fixed-link, the MDIO bus is skipped. + +Tested on a sama5d35 based system with a ksz8863 switch attached to +macb0. + +Fixes: 79540d133ed6 ("net: macb: Fix handling of fixed-link node") +Signed-off-by: Oleksij Rempel +Cc: stable@vger.kernel.org +Reviewed-by: Andrew Lunn +Link: https://patch.msgid.link/20241013052916.3115142-1-o.rempel@pengutronix.de +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/cadence/macb_main.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +--- a/drivers/net/ethernet/cadence/macb_main.c ++++ b/drivers/net/ethernet/cadence/macb_main.c +@@ -902,9 +902,6 @@ static int macb_mdiobus_register(struct + { + struct device_node *child, *np = bp->pdev->dev.of_node; + +- if (of_phy_is_fixed_link(np)) +- return mdiobus_register(bp->mii_bus); +- + /* Only create the PHY from the device tree if at least one PHY is + * described. Otherwise scan the entire MDIO bus. We do this to support + * old device tree that did not follow the best practices and did not +@@ -925,8 +922,19 @@ static int macb_mdiobus_register(struct + + static int macb_mii_init(struct macb *bp) + { ++ struct device_node *child, *np = bp->pdev->dev.of_node; + int err = -ENXIO; + ++ /* With fixed-link, we don't need to register the MDIO bus, ++ * except if we have a child named "mdio" in the device tree. ++ * In that case, some devices may be attached to the MACB's MDIO bus. ++ */ ++ child = of_get_child_by_name(np, "mdio"); ++ if (child) ++ of_node_put(child); ++ else if (of_phy_is_fixed_link(np)) ++ return macb_mii_probe(bp->dev); ++ + /* Enable management port */ + macb_writel(bp, NCR, MACB_BIT(MPE)); + diff --git a/queue-5.15/posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch b/queue-5.15/posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch new file mode 100644 index 00000000000..b39e716da04 --- /dev/null +++ b/queue-5.15/posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch @@ -0,0 +1,52 @@ +From d8794ac20a299b647ba9958f6d657051fc51a540 Mon Sep 17 00:00:00 2001 +From: Jinjie Ruan +Date: Wed, 9 Oct 2024 15:23:01 +0800 +Subject: posix-clock: Fix missing timespec64 check in pc_clock_settime() + +From: Jinjie Ruan + +commit d8794ac20a299b647ba9958f6d657051fc51a540 upstream. + +As Andrew pointed out, it will make sense that the PTP core +checked timespec64 struct's tv_sec and tv_nsec range before calling +ptp->info->settime64(). + +As the man manual of clock_settime() said, if tp.tv_sec is negative or +tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, +which include dynamic clocks which handles PTP clock, and the condition is +consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() +only check the timespec is valid, but not ensure that the time is +in a valid range, so check it ahead using timespec64_valid_strict() +in pc_clock_settime() and return -EINVAL if not valid. + +There are some drivers that use tp->tv_sec and tp->tv_nsec directly to +write registers without validity checks and assume that the higher layer +has checked it, which is dangerous and will benefit from this, such as +hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), +and some drivers can remove the checks of itself. + +Cc: stable@vger.kernel.org +Fixes: 0606f422b453 ("posix clocks: Introduce dynamic clocks") +Acked-by: Richard Cochran +Suggested-by: Andrew Lunn +Suggested-by: Thomas Gleixner +Signed-off-by: Jinjie Ruan +Link: https://patch.msgid.link/20241009072302.1754567-2-ruanjinjie@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + kernel/time/posix-clock.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/time/posix-clock.c ++++ b/kernel/time/posix-clock.c +@@ -299,6 +299,9 @@ static int pc_clock_settime(clockid_t id + goto out; + } + ++ if (!timespec64_valid_strict(ts)) ++ return -EINVAL; ++ + if (cd.clk->ops.clock_settime) + err = cd.clk->ops.clock_settime(cd.clk, ts); + else diff --git a/queue-5.15/series b/queue-5.15/series index 0dfbf1d3c24..433ae272d81 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -19,3 +19,10 @@ udf-remove-old-directory-iteration-code.patch udf-handle-error-when-expanding-directory.patch udf-don-t-return-bh-from-udf_expand_dir_adinicb.patch udf-fix-bogus-checksum-computation-in-udf_rename.patch +net-enetc-remove-xdp_drops-statistic-from-enetc_xdp_drop.patch +net-enetc-add-missing-static-descriptor-and-inline-keyword.patch +posix-clock-fix-missing-timespec64-check-in-pc_clock_settime.patch +arm64-probes-remove-broken-ldr-literal-uprobe-support.patch +arm64-probes-fix-simulate_ldr-_literal.patch +net-macb-avoid-20s-boot-delay-by-skipping-mdio-bus-registration-for-fixed-link-phy.patch +irqchip-gic-v3-its-fix-vsync-referencing-an-unmapped-vpe-on-gic-v4.1.patch -- 2.47.3