--- /dev/null
+From 50f813e57601c22b6f26ced3193b9b94d70a2640 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Tue, 8 Oct 2024 16:58:47 +0100
+Subject: arm64: probes: Fix simulate_ldr*_literal()
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+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 <mark.rutland@arm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241008155851.801546-3-mark.rutland@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -178,17 +178,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);
+ }
+@@ -196,14 +194,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);
+ }
--- /dev/null
+From acc450aa07099d071b18174c22a1119c57da8227 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Tue, 8 Oct 2024 16:58:46 +0100
+Subject: arm64: probes: Remove broken LDR (literal) uprobe support
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+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 <mark.rutland@arm.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20241008155851.801546-2-mark.rutland@arm.com
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -104,10 +104,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
+@@ -145,6 +141,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
+@@ -162,7 +169,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))
--- /dev/null
+From 963a7f4d3b90ee195b895ca06b95757fcba02d1a Mon Sep 17 00:00:00 2001
+From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
+Date: Fri, 4 Oct 2024 15:03:49 +0900
+Subject: fat: fix uninitialized variable
+
+From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
+
+commit 963a7f4d3b90ee195b895ca06b95757fcba02d1a upstream.
+
+syszbot produced this with a corrupted fs image. In theory, however an IO
+error would trigger this also.
+
+This affects just an error report, so should not be a serious error.
+
+Link: https://lkml.kernel.org/r/87r08wjsnh.fsf@mail.parknet.co.jp
+Link: https://lkml.kernel.org/r/66ff2c95.050a0220.49194.03e9.GAE@google.com
+Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
+Reported-by: syzbot+ef0d7bc412553291aa86@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fat/namei_vfat.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/fat/namei_vfat.c
++++ b/fs/fat/namei_vfat.c
+@@ -1018,7 +1018,7 @@ error_inode:
+ if (corrupt < 0) {
+ fat_fs_error(new_dir->i_sb,
+ "%s: Filesystem corrupted (i_pos %lld)",
+- __func__, sinfo.i_pos);
++ __func__, new_i_pos);
+ }
+ goto out;
+ }
--- /dev/null
+From 9246b487ab3c3b5993aae7552b7a4c541cc14a49 Mon Sep 17 00:00:00 2001
+From: WangYuli <wangyuli@uniontech.com>
+Date: Fri, 23 Aug 2024 17:57:08 +0800
+Subject: PCI: Add function 0 DMA alias quirk for Glenfly Arise chip
+
+From: WangYuli <wangyuli@uniontech.com>
+
+commit 9246b487ab3c3b5993aae7552b7a4c541cc14a49 upstream.
+
+Add DMA support for audio function of Glenfly Arise chip, which uses
+Requester ID of function 0.
+
+Link: https://lore.kernel.org/r/CA2BBD087345B6D1+20240823095708.3237375-1-wangyuli@uniontech.com
+Signed-off-by: SiyuLi <siyuli@glenfly.com>
+Signed-off-by: WangYuli <wangyuli@uniontech.com>
+[bhelgaas: lower-case hex to match local code, drop unused Device IDs]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/quirks.c | 4 ++++
+ include/linux/pci_ids.h | 2 ++
+ 2 files changed, 6 insertions(+)
+
+--- a/drivers/pci/quirks.c
++++ b/drivers/pci/quirks.c
+@@ -4044,6 +4044,10 @@ static void quirk_dma_func0_alias(struct
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe832, quirk_dma_func0_alias);
+ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_RICOH, 0xe476, quirk_dma_func0_alias);
+
++/* Some Glenfly chips use function 0 as the PCIe Requester ID for DMA */
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_GLENFLY, 0x3d40, quirk_dma_func0_alias);
++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_GLENFLY, 0x3d41, quirk_dma_func0_alias);
++
+ static void quirk_dma_func1_alias(struct pci_dev *dev)
+ {
+ if (PCI_FUNC(dev->devfn) != 1)
+--- a/include/linux/pci_ids.h
++++ b/include/linux/pci_ids.h
+@@ -2647,6 +2647,8 @@
+ #define PCI_DEVICE_ID_DCI_PCCOM8 0x0002
+ #define PCI_DEVICE_ID_DCI_PCCOM2 0x0004
+
++#define PCI_VENDOR_ID_GLENFLY 0x6766
++
+ #define PCI_VENDOR_ID_INTEL 0x8086
+ #define PCI_DEVICE_ID_INTEL_EESSC 0x0008
+ #define PCI_DEVICE_ID_INTEL_PXHD_0 0x0320
--- /dev/null
+From d8794ac20a299b647ba9958f6d657051fc51a540 Mon Sep 17 00:00:00 2001
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+Date: Wed, 9 Oct 2024 15:23:01 +0800
+Subject: posix-clock: Fix missing timespec64 check in pc_clock_settime()
+
+From: Jinjie Ruan <ruanjinjie@huawei.com>
+
+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 <richardcochran@gmail.com>
+Suggested-by: Andrew Lunn <andrew@lunn.ch>
+Suggested-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
+Link: https://patch.msgid.link/20241009072302.1754567-2-ruanjinjie@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/time/posix-clock.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/time/posix-clock.c
++++ b/kernel/time/posix-clock.c
+@@ -312,6 +312,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
usb-xhci-fix-problem-with-xhci-resume-from-suspend.patch
usb-storage-ignore-bogus-device-raised-by-jieli-br21-usb-sound-chip.patch
net-fix-an-unsafe-loop-on-the-list.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
+pci-add-function-0-dma-alias-quirk-for-glenfly-arise-chip.patch
+fat-fix-uninitialized-variable.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
