Re: kernel BUG in ptr_stale
On Thu, May 09, 2024 at 02:26:24PM +0800, Ubisectech Sirius wrote: > Hello. > We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. > Recently, our team has discovered a issue in Linux kernel 6.7. Attached to > the email were a PoC file of the issue. This (and several of your others) are fixed in Linus's tree. > > Stack dump: > > bcachefs (loop1): mounting version 1.7: (unknown version) > opts=metadata_checksum=none,data_checksum=none,nojournal_transaction_names > [ cut here ] > kernel BUG at fs/bcachefs/buckets.h:114! > invalid opcode: [#1] PREEMPT SMP KASAN NOPTI > CPU: 1 PID: 9472 Comm: syz-executor.1 Not tainted 6.7.0 #2 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 > 04/01/2014 > RIP: 0010:bucket_gen fs/bcachefs/buckets.h:114 [inline] > RIP: 0010:ptr_stale+0x474/0x4e0 fs/bcachefs/buckets.h:188 > Code: 48 c7 c2 80 8c 1b 8b be 67 00 00 00 48 c7 c7 e0 8c 1b 8b c6 05 ea a6 72 > 0b 01 e8 57 55 9c fd e9 fb fc ff ff e8 9d 02 bd fd 90 <0f> 0b 48 89 04 24 e8 > 31 bb 13 fe 48 8b 04 24 e9 35 fc ff ff e8 23 > RSP: 0018:c90007c4ec38 EFLAGS: 00010246 > RAX: 0004 RBX: 0080 RCX: c90002679000 > RDX: 0004 RSI: 83ccf3b3 RDI: 0006 > RBP: R08: 0006 R09: 1028 > R10: 0080 R11: R12: 1028 > R13: 88804dee5100 R14: R15: 88805b1a4110 > FS: 7f79ba8ab640() GS:88807ec0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f0bbda3f000 CR3: 5f37a000 CR4: 00750ef0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > PKRU: 5554 > Call Trace: > > bch2_bkey_ptrs_to_text+0xb4e/0x1760 fs/bcachefs/extents.c:1012 > bch2_btree_ptr_v2_to_text+0x288/0x330 fs/bcachefs/extents.c:215 > bch2_val_to_text fs/bcachefs/bkey_methods.c:287 [inline] > bch2_bkey_val_to_text+0x1c8/0x210 fs/bcachefs/bkey_methods.c:297 > journal_validate_key+0x7ab/0xb50 fs/bcachefs/journal_io.c:322 > journal_entry_btree_root_validate+0x31c/0x380 fs/bcachefs/journal_io.c:411 > bch2_journal_entry_validate+0xc7/0x130 fs/bcachefs/journal_io.c:752 > bch2_sb_clean_validate_late+0x14b/0x1e0 fs/bcachefs/sb-clean.c:32 > bch2_read_superblock_clean+0xbb/0x250 fs/bcachefs/sb-clean.c:160 > bch2_fs_recovery+0x113/0x52d0 fs/bcachefs/recovery.c:691 > bch2_fs_start+0x365/0x5e0 fs/bcachefs/super.c:978 > bch2_fs_open+0x1ac9/0x3890 fs/bcachefs/super.c:1968 > bch2_mount+0x538/0x13c0 fs/bcachefs/fs.c:1863 > legacy_get_tree+0x109/0x220 fs/fs_context.c:662 > vfs_get_tree+0x93/0x380 fs/super.c:1771 > do_new_mount fs/namespace.c:3337 [inline] > path_mount+0x679/0x1e40 fs/namespace.c:3664 > do_mount fs/namespace.c:3677 [inline] > __do_sys_mount fs/namespace.c:3886 [inline] > __se_sys_mount fs/namespace.c:3863 [inline] > __x64_sys_mount+0x287/0x310 fs/namespace.c:3863 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x6f/0x77 > RIP: 0033:0x7f79b9a91b3e > Code: 48 c7 c0 ff ff ff ff eb aa e8 be 0d 00 00 66 2e 0f 1f 84 00 00 00 00 00 > 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 > 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:7f79ba8aae38 EFLAGS: 0202 ORIG_RAX: 00a5 > RAX: ffda RBX: 000119f4 RCX: 7f79b9a91b3e > RDX: 20011a00 RSI: 20011a40 RDI: 7f79ba8aae90 > RBP: 7f79ba8aaed0 R08: 7f79ba8aaed0 R09: 0181c050 > R10: 0181c050 R11: 0202 R12: 20011a00 > R13: 20011a40 R14: 7f79ba8aae90 R15: 21c0 > > Modules linked in: > ---[ end trace ]--- > > > Thank you for taking the time to read this email and we look forward to > working with you further. > > > > > >
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 5/9/24 10:32 AM, Mathieu Poirier wrote:
On Wed, 8 May 2024 at 10:54, Andrew Davis wrote:
On 5/7/24 3:36 PM, Mathieu Poirier wrote:
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+tristate "TI K3 M4 remoteproc support"
+depends on ARCH_K3 || COMPILE_TEST
+select MAILBOX
+select OMAP2PLUS_MBOX
+help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+void __iomem *cpu_addr;
+phys_addr_t bus_addr;
+u32 dev_addr;
+size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+const char *name;
+const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+const struct k3_m4_rproc_mem_data *mems;
+u32 num_mems;
+bool uses_lreset;
+};
+
+/**
+ * struct k3_m4_rproc - k3 remote processor driver structure
+ * @dev: cached device pointer
+ * @rproc:
Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support
On Thu, 2024-05-09 at 10:30 +0200, Jiri Olsa wrote: > > Per the earlier discussion, this cannot be reached unless uretprobes are in > > use, > > which cannot happen without something with privileges taking an action. But > > are > > uretprobes ever used for monitoring applications where security is > > important? Or > > is it strictly a debug-time thing? > > sorry, I don't have that level of detail, but we do have customers > that use uprobes in general or want to use it and complain about > the speed > > there are several tools in bcc [1] that use uretprobes in scripts, > like: > memleak, sslsniff, trace, bashreadline, gethostlatency, argdist, > funclatency Is it possible to have shadow stack only use the non-syscall solution? It seems it exposes a more limited compatibility in that it only allows writing the specific trampoline address. (IIRC) Then shadow stack users could still use uretprobes, but just not the new optimized solution. There are already operations that are slower with shadow stack, like longjmp(), so this could be ok maybe.
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On 5/9/24 10:22 AM, Mathieu Poirier wrote:
On Wed, 8 May 2024 at 09:36, Andrew Davis wrote:
On 5/6/24 3:46 PM, Mathieu Poirier wrote:
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done with the
review.
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However, some application (non safety related) may
want to use the M4F core as a generic remote processor with IPC to the
host processor. The M4F core has internal IRAM and DRAM memories and are
exposed to the system bus for code and data loading.
A remote processor driver is added to support this subsystem, including
being able to load and boot the M4F core. Loading includes to M4F
internal memories and predefined external code/data memories. The
carve outs for external contiguous memory is defined in the M4F device
node and should match with the external memory declarations in the M4F
image binary. The M4F subsystem has two resets. One reset is for the
entire subsystem i.e including the internal memories and the other, a
local reset is only for the M4F processing core. When loading the image,
the driver first releases the subsystem reset, loads the firmware image
and then releases the local reset to let the M4F processing core run.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 48845dc8fa852..1a7c0330c91a9 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
It's safe to say N here if you're not interested in utilizing
the DSP slave processors.
+config TI_K3_M4_REMOTEPROC
+tristate "TI K3 M4 remoteproc support"
+depends on ARCH_K3 || COMPILE_TEST
+select MAILBOX
+select OMAP2PLUS_MBOX
+help
+ Say m here to support TI's M4 remote processor subsystems
+ on various TI K3 family of SoCs through the remote processor
+ framework.
+
+ It's safe to say N here if you're not interested in utilizing
+ a remote processor.
+
config TI_K3_R5_REMOTEPROC
tristate "TI K3 R5 remoteproc support"
depends on ARCH_K3
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 91314a9b43cef..5ff4e2fee4abd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
+obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
b/drivers/remoteproc/ti_k3_m4_remoteproc.c
new file mode 100644
index 0..0030e509f6b5d
--- /dev/null
+++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
@@ -0,0 +1,785 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * TI K3 Cortex-M4 Remote Processor(s) driver
+ *
+ * Copyright (C) 2021-2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Hari Nagalla
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "omap_remoteproc.h"
+#include "remoteproc_internal.h"
+#include "ti_sci_proc.h"
+
+/**
+ * struct k3_m4_rproc_mem - internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @bus_addr: Bus address used to access the memory region
+ * @dev_addr: Device address of the memory region from remote processor view
+ * @size: Size of the memory region
+ */
+struct k3_m4_rproc_mem {
+void __iomem *cpu_addr;
+phys_addr_t bus_addr;
+u32 dev_addr;
+size_t size;
+};
+
+/**
+ * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
+ * @name: name for this memory entry
+ * @dev_addr: device address for the memory entry
+ */
+struct k3_m4_rproc_mem_data {
+const char *name;
+const u32 dev_addr;
+};
+
+/**
+ * struct k3_m4_rproc_dev_data - device data structure for a remote processor
+ * @mems: pointer to memory definitions for a remote processor
+ * @num_mems: number of memory regions in @mems
+ * @uses_lreset: flag to denote the need for local reset management
+ */
+struct k3_m4_rproc_dev_data {
+const struct
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On Wed, 8 May 2024 at 10:54, Andrew Davis wrote:
>
> On 5/7/24 3:36 PM, Mathieu Poirier wrote:
> > On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
> >> From: Martyn Welch
> >>
> >> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> >> the MCU domain. This core is typically used for safety applications in a
> >> stand alone mode. However, some application (non safety related) may
> >> want to use the M4F core as a generic remote processor with IPC to the
> >> host processor. The M4F core has internal IRAM and DRAM memories and are
> >> exposed to the system bus for code and data loading.
> >>
> >> A remote processor driver is added to support this subsystem, including
> >> being able to load and boot the M4F core. Loading includes to M4F
> >> internal memories and predefined external code/data memories. The
> >> carve outs for external contiguous memory is defined in the M4F device
> >> node and should match with the external memory declarations in the M4F
> >> image binary. The M4F subsystem has two resets. One reset is for the
> >> entire subsystem i.e including the internal memories and the other, a
> >> local reset is only for the M4F processing core. When loading the image,
> >> the driver first releases the subsystem reset, loads the firmware image
> >> and then releases the local reset to let the M4F processing core run.
> >>
> >> Signed-off-by: Martyn Welch
> >> Signed-off-by: Hari Nagalla
> >> Signed-off-by: Andrew Davis
> >> ---
> >> drivers/remoteproc/Kconfig | 13 +
> >> drivers/remoteproc/Makefile | 1 +
> >> drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
> >> 3 files changed, 799 insertions(+)
> >> create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> >>
> >> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> >> index 48845dc8fa852..1a7c0330c91a9 100644
> >> --- a/drivers/remoteproc/Kconfig
> >> +++ b/drivers/remoteproc/Kconfig
> >> @@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
> >>It's safe to say N here if you're not interested in utilizing
> >>the DSP slave processors.
> >>
> >> +config TI_K3_M4_REMOTEPROC
> >> +tristate "TI K3 M4 remoteproc support"
> >> +depends on ARCH_K3 || COMPILE_TEST
> >> +select MAILBOX
> >> +select OMAP2PLUS_MBOX
> >> +help
> >> + Say m here to support TI's M4 remote processor subsystems
> >> + on various TI K3 family of SoCs through the remote processor
> >> + framework.
> >> +
> >> + It's safe to say N here if you're not interested in utilizing
> >> + a remote processor.
> >> +
> >> config TI_K3_R5_REMOTEPROC
> >> tristate "TI K3 R5 remoteproc support"
> >> depends on ARCH_K3
> >> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> >> index 91314a9b43cef..5ff4e2fee4abd 100644
> >> --- a/drivers/remoteproc/Makefile
> >> +++ b/drivers/remoteproc/Makefile
> >> @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)+=
> >> st_remoteproc.o
> >> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> >> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> >> obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> >> +obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
> >> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> >> obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> >> diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
> >> b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> >> new file mode 100644
> >> index 0..0030e509f6b5d
> >> --- /dev/null
> >> +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> >> @@ -0,0 +1,785 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/*
> >> + * TI K3 Cortex-M4 Remote Processor(s) driver
> >> + *
> >> + * Copyright (C) 2021-2024 Texas Instruments Incorporated -
> >> https://www.ti.com/
> >> + * Hari Nagalla
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "omap_remoteproc.h"
> >> +#include "remoteproc_internal.h"
> >> +#include "ti_sci_proc.h"
> >> +
> >> +/**
> >> + * struct k3_m4_rproc_mem - internal memory structure
> >> + * @cpu_addr: MPU virtual address of the memory region
> >> + * @bus_addr: Bus address used to access the memory region
> >> + * @dev_addr: Device address of the memory region from remote processor
> >> view
> >> + * @size: Size of the memory region
> >> + */
> >> +struct k3_m4_rproc_mem {
> >> +void __iomem *cpu_addr;
> >> +phys_addr_t bus_addr;
> >> +u32 dev_addr;
> >> +size_t size;
> >> +};
> >> +
> >> +/**
> >> + * struct k3_m4_rproc_mem_data - memory definitions for a remote processor
> >> + * @name: name for this memory entry
> >> + * @dev_addr: device address for the memory entry
> >> + */
> >> +struct k3_m4_rproc_mem_data {
> >> +const char *name;
> >>
Re: [PATCH v9 2/5] remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem
On Wed, 8 May 2024 at 09:36, Andrew Davis wrote:
>
> On 5/6/24 3:46 PM, Mathieu Poirier wrote:
> > Good day,
> >
> > I have started reviewing this patchset. Comments will be scattered over
> > multiple days and as such, I will explicitly inform you when am done with
> > the
> > review.
> >
> > On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
> >> From: Martyn Welch
> >>
> >> The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
> >> the MCU domain. This core is typically used for safety applications in a
> >> stand alone mode. However, some application (non safety related) may
> >> want to use the M4F core as a generic remote processor with IPC to the
> >> host processor. The M4F core has internal IRAM and DRAM memories and are
> >> exposed to the system bus for code and data loading.
> >>
> >> A remote processor driver is added to support this subsystem, including
> >> being able to load and boot the M4F core. Loading includes to M4F
> >> internal memories and predefined external code/data memories. The
> >> carve outs for external contiguous memory is defined in the M4F device
> >> node and should match with the external memory declarations in the M4F
> >> image binary. The M4F subsystem has two resets. One reset is for the
> >> entire subsystem i.e including the internal memories and the other, a
> >> local reset is only for the M4F processing core. When loading the image,
> >> the driver first releases the subsystem reset, loads the firmware image
> >> and then releases the local reset to let the M4F processing core run.
> >>
> >> Signed-off-by: Martyn Welch
> >> Signed-off-by: Hari Nagalla
> >> Signed-off-by: Andrew Davis
> >> ---
> >> drivers/remoteproc/Kconfig | 13 +
> >> drivers/remoteproc/Makefile | 1 +
> >> drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
> >> 3 files changed, 799 insertions(+)
> >> create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
> >>
> >> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> >> index 48845dc8fa852..1a7c0330c91a9 100644
> >> --- a/drivers/remoteproc/Kconfig
> >> +++ b/drivers/remoteproc/Kconfig
> >> @@ -339,6 +339,19 @@ config TI_K3_DSP_REMOTEPROC
> >>It's safe to say N here if you're not interested in utilizing
> >>the DSP slave processors.
> >>
> >> +config TI_K3_M4_REMOTEPROC
> >> +tristate "TI K3 M4 remoteproc support"
> >> +depends on ARCH_K3 || COMPILE_TEST
> >> +select MAILBOX
> >> +select OMAP2PLUS_MBOX
> >> +help
> >> + Say m here to support TI's M4 remote processor subsystems
> >> + on various TI K3 family of SoCs through the remote processor
> >> + framework.
> >> +
> >> + It's safe to say N here if you're not interested in utilizing
> >> + a remote processor.
> >> +
> >> config TI_K3_R5_REMOTEPROC
> >> tristate "TI K3 R5 remoteproc support"
> >> depends on ARCH_K3
> >> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> >> index 91314a9b43cef..5ff4e2fee4abd 100644
> >> --- a/drivers/remoteproc/Makefile
> >> +++ b/drivers/remoteproc/Makefile
> >> @@ -37,5 +37,6 @@ obj-$(CONFIG_ST_REMOTEPROC)+=
> >> st_remoteproc.o
> >> obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
> >> obj-$(CONFIG_STM32_RPROC) += stm32_rproc.o
> >> obj-$(CONFIG_TI_K3_DSP_REMOTEPROC) += ti_k3_dsp_remoteproc.o
> >> +obj-$(CONFIG_TI_K3_M4_REMOTEPROC) += ti_k3_m4_remoteproc.o
> >> obj-$(CONFIG_TI_K3_R5_REMOTEPROC) += ti_k3_r5_remoteproc.o
> >> obj-$(CONFIG_XLNX_R5_REMOTEPROC) += xlnx_r5_remoteproc.o
> >> diff --git a/drivers/remoteproc/ti_k3_m4_remoteproc.c
> >> b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> >> new file mode 100644
> >> index 0..0030e509f6b5d
> >> --- /dev/null
> >> +++ b/drivers/remoteproc/ti_k3_m4_remoteproc.c
> >> @@ -0,0 +1,785 @@
> >> +// SPDX-License-Identifier: GPL-2.0-only
> >> +/*
> >> + * TI K3 Cortex-M4 Remote Processor(s) driver
> >> + *
> >> + * Copyright (C) 2021-2024 Texas Instruments Incorporated -
> >> https://www.ti.com/
> >> + * Hari Nagalla
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "omap_remoteproc.h"
> >> +#include "remoteproc_internal.h"
> >> +#include "ti_sci_proc.h"
> >> +
> >> +/**
> >> + * struct k3_m4_rproc_mem - internal memory structure
> >> + * @cpu_addr: MPU virtual address of the memory region
> >> + * @bus_addr: Bus address used to access the memory region
> >> + * @dev_addr: Device address of the memory region from remote processor
> >> view
> >> + * @size: Size of the memory region
> >> + */
> >> +struct k3_m4_rproc_mem {
> >> +void __iomem *cpu_addr;
> >> +phys_addr_t bus_addr;
> >> +u32 dev_addr;
> >> +size_t size;
> >> +};
> >> +
> >> +/**
> >> + * struct k3_m4_rproc_mem_data - memory definitions
Re: [PATCH 1/1] livepatch: Rename KLP_* to KLP_TRANSITION_*
On Tue 2024-05-07 13:01:11, zhangwar...@gmail.com wrote: > From: Wardenjohn > > The original macros of KLP_* is about the state of the transition. > Rename macros of KLP_* to KLP_TRANSITION_* to fix the confusing > description of klp transition state. > > Signed-off-by: Wardenjohn JFYI, the patch has been comitted into livepatching.git, branch for-10. Best regards, Petr
Re: [PATCH v2] module: create weak dependecies
On Thu, May 09, 2024 at 12:24:40PM GMT, Jose Ignacio Tornos Martinez wrote:
It has been seen that for some network mac drivers (i.e. lan78xx) the
related module for the phy is loaded dynamically depending on the current
hardware. In this case, the associated phy is read using mdio bus and then
the associated phy module is loaded during runtime (kernel function
phy_request_driver_module). However, no software dependency is defined, so
the user tools will no be able to get this dependency. For example, if
dracut is used and the hardware is present, lan78xx will be included but no
phy module will be added, and in the next restart the device will not work
from boot because no related phy will be found during initramfs stage.
In order to solve this, we could define a normal 'pre' software dependency
in lan78xx module with all the possible phy modules (there may be some),
but proceeding in that way, all the possible phy modules would be loaded
while only one is necessary.
The idea is to create a new type of dependency, that we are going to call
'weak' to be used only by the user tools that need to detect this situation.
In that way, for example, dracut could check the 'weak' dependency of the
modules involved in order to install these dependencies in initramfs too.
That is, for the commented lan78xx module, defining the 'weak' dependency
with the possible phy modules list, only the necessary phy would be loaded
on demand keeping the same behavior, but all the possible phy modules would
be available from initramfs.
I think it's important a note about backward compatibility. If a system
doesn't have a new-enough depmod, it will basically not create the new
weadep file and initrd generators won't be able to use that. Only
downside is not being able to use the new feature, but it should still
work as previously.
The 'weak' dependency support has been included in kmod:
https://github.com/kmod-project/kmod/commit/05828b4a6e9327a63ef94df544a042b5e9ce4fe7
Signed-off-by: Jose Ignacio Tornos Martinez
---
V1 -> V2:
- Include reference to 'weak' dependency support in kmod.
include/linux/module.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/module.h b/include/linux/module.h
index 1153b0d99a80..231e710d8736 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -173,6 +173,11 @@ extern void cleanup_module(void);
*/
#define MODULE_SOFTDEP(_softdep) MODULE_INFO(softdep, _softdep)
+/* Weak module dependencies. See man modprobe.d for details.
Documentation/process/coding-style.rst section 8 says to balance the /*
and */, but up to Luis what he enforces in the module tree.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+ * Example: MODULE_WEAKDEP("module-foo")
+ */
+#define MODULE_WEAKDEP(_weakdep) MODULE_INFO(weakdep, _weakdep)
+
/*
* MODULE_FILE is used for generating modules.builtin
* So, make it no-op when this is being built as a module
--
2.44.0
Re: [PATCH 1/1] livepatch: Rename KLP_* to KLP_TRANSITION_*
On Tue, 7 May 2024, zhangwar...@gmail.com wrote: > From: Wardenjohn > > The original macros of KLP_* is about the state of the transition. > Rename macros of KLP_* to KLP_TRANSITION_* to fix the confusing > description of klp transition state. > > Signed-off-by: Wardenjohn Acked-by: Miroslav Benes M
[PATCH v1 1/1] Input: gpio-keys - expose wakeup keys in sysfs
This helps user space to figure out which keys should be used to unidle a
device. E.g on phones the volume rocker should usually not unblank the
screen.
Signed-off-by: Guido Günther
---
drivers/input/keyboard/gpio_keys.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/input/keyboard/gpio_keys.c
b/drivers/input/keyboard/gpio_keys.c
index 9f3bcd41cf67..84f43d1d4375 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -198,7 +198,8 @@ static void gpio_keys_enable_button(struct gpio_button_data
*bdata)
*/
static ssize_t gpio_keys_attr_show_helper(struct gpio_keys_drvdata *ddata,
char *buf, unsigned int type,
- bool only_disabled)
+ bool only_disabled,
+ bool only_wakeup)
{
int n_events = get_n_events_by_type(type);
unsigned long *bits;
@@ -218,6 +219,9 @@ static ssize_t gpio_keys_attr_show_helper(struct
gpio_keys_drvdata *ddata,
if (only_disabled && !bdata->disabled)
continue;
+ if (only_wakeup && !bdata->button->wakeup)
+ continue;
+
__set_bit(*bdata->code, bits);
}
@@ -297,7 +301,7 @@ static ssize_t gpio_keys_attr_store_helper(struct
gpio_keys_drvdata *ddata,
return error;
}
-#define ATTR_SHOW_FN(name, type, only_disabled)
\
+#define ATTR_SHOW_FN(name, type, only_disabled, only_wakeup) \
static ssize_t gpio_keys_show_##name(struct device *dev, \
struct device_attribute *attr, \
char *buf) \
@@ -306,22 +310,26 @@ static ssize_t gpio_keys_show_##name(struct device *dev,
\
struct gpio_keys_drvdata *ddata = platform_get_drvdata(pdev); \
\
return gpio_keys_attr_show_helper(ddata, buf, \
- type, only_disabled); \
+ type, only_disabled, \
+ only_wakeup); \
}
-ATTR_SHOW_FN(keys, EV_KEY, false);
-ATTR_SHOW_FN(switches, EV_SW, false);
-ATTR_SHOW_FN(disabled_keys, EV_KEY, true);
-ATTR_SHOW_FN(disabled_switches, EV_SW, true);
+ATTR_SHOW_FN(keys, EV_KEY, false, false);
+ATTR_SHOW_FN(switches, EV_SW, false, false);
+ATTR_SHOW_FN(disabled_keys, EV_KEY, true, false);
+ATTR_SHOW_FN(disabled_switches, EV_SW, true, false);
+ATTR_SHOW_FN(wakeup_keys, EV_KEY, false, true);
/*
* ATTRIBUTES:
*
* /sys/devices/platform/gpio-keys/keys [ro]
* /sys/devices/platform/gpio-keys/switches [ro]
+ * /sys/devices/platform/gpio-keys/wakeup_keys [ro]
*/
static DEVICE_ATTR(keys, S_IRUGO, gpio_keys_show_keys, NULL);
static DEVICE_ATTR(switches, S_IRUGO, gpio_keys_show_switches, NULL);
+static DEVICE_ATTR(wakeup_keys, S_IRUGO, gpio_keys_show_wakeup_keys, NULL);
#define ATTR_STORE_FN(name, type) \
static ssize_t gpio_keys_store_##name(struct device *dev, \
@@ -361,6 +369,7 @@ static struct attribute *gpio_keys_attrs[] = {
_attr_switches.attr,
_attr_disabled_keys.attr,
_attr_disabled_switches.attr,
+ _attr_wakeup_keys.attr,
NULL,
};
ATTRIBUTE_GROUPS(gpio_keys);
--
2.43.0
[PATCH v4] ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr 888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: GW 6.9.0-rc2+
[...]
Call Trace:
dump_stack_lvl+0x68/0xa0
print_report+0xcf/0x610
kasan_report+0xb5/0xe0
ftrace_location+0x90/0x120
register_kprobe+0x14b/0xa40
kprobe_init+0x2d/0xff0 [kprobe_example]
do_one_initcall+0x8f/0x2d0
do_init_module+0x13a/0x3c0
load_module+0x3082/0x33d0
init_module_from_file+0xd2/0x130
__x64_sys_finit_module+0x306/0x440
do_syscall_64+0x68/0x140
entry_SYSCALL_64_after_hwframe+0x71/0x79
The root cause is that, in lookup_rec(), ftrace record of some address
is being searched in ftrace pages of some module, but those ftrace pages
at the same time is being freed in ftrace_release_mod() as the
corresponding module is being deleted:
CPU1 | CPU2
register_kprobes() {| delete_module() {
check_kprobe_address_safe() { |
arch_check_ftrace_location() { |
ftrace_location() { |
lookup_rec() // USE!| ftrace_release_mod() // Free!
To fix this issue:
1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
2. Use ftrace_location_range() instead of lookup_rec() in
ftrace_location();
3. Call synchronize_rcu() before freeing any ftrace pages both in
ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().
Fixes: ae6aa16fdc16 ("kprobes: introduce ftrace based optimization")
Suggested-by: Steven Rostedt
Signed-off-by: Zheng Yejian
---
kernel/trace/ftrace.c | 39 +++
1 file changed, 23 insertions(+), 16 deletions(-)
v4:
- Simply add rcu locking into ftrace_location_range() as suggested by Steve.
Link:
https://lore.kernel.org/linux-trace-kernel/20240502170743.15a5f...@gandalf.local.home/
v3:
- Complete the commit description and add Suggested-by tag
- Add comments around where synchronize_rcu() is called
- Link:
https://lore.kernel.org/linux-trace-kernel/20240417032830.1764690-1-zhengyeji...@huawei.com/
v2:
- Link:
https://lore.kernel.org/all/20240416112459.1444612-1-zhengyeji...@huawei.com/
- Use RCU lock instead of holding ftrace_lock as suggested by Steve.
Link: https://lore.kernel.org/all/20240410112823.1d084...@gandalf.local.home/
v1:
- Link:
https://lore.kernel.org/all/20240401125543.1282845-1-zhengyeji...@huawei.com/
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index da1710499698..1e12df9bb531 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -1595,12 +1595,15 @@ static struct dyn_ftrace *lookup_rec(unsigned long
start, unsigned long end)
unsigned long ftrace_location_range(unsigned long start, unsigned long end)
{
struct dyn_ftrace *rec;
+ unsigned long ip = 0;
+ rcu_read_lock();
rec = lookup_rec(start, end);
if (rec)
- return rec->ip;
+ ip = rec->ip;
+ rcu_read_unlock();
- return 0;
+ return ip;
}
/**
@@ -1614,25 +1617,22 @@ unsigned long ftrace_location_range(unsigned long
start, unsigned long end)
*/
unsigned long ftrace_location(unsigned long ip)
{
- struct dyn_ftrace *rec;
+ unsigned long loc;
unsigned long offset;
unsigned long size;
- rec = lookup_rec(ip, ip);
- if (!rec) {
+ loc = ftrace_location_range(ip, ip);
+ if (!loc) {
if (!kallsyms_lookup_size_offset(ip, , ))
goto out;
/* map sym+0 to __fentry__ */
if (!offset)
- rec = lookup_rec(ip, ip + size - 1);
+ loc = ftrace_location_range(ip, ip + size - 1);
}
- if (rec)
- return rec->ip;
-
out:
- return 0;
+ return loc;
}
/**
@@ -6596,6 +6596,8 @@ static int ftrace_process_locs(struct module *mod,
/* We should have used all pages unless we skipped some */
if (pg_unuse) {
WARN_ON(!skipped);
+ /* Need to synchronize with ftrace_location_range() */
+ synchronize_rcu();
ftrace_free_pages(pg_unuse);
}
return ret;
@@ -6809,6 +6811,9 @@ void ftrace_release_mod(struct module *mod)
out_unlock:
mutex_unlock(_lock);
+ /* Need to synchronize with ftrace_location_range() */
+ if (tmp_page)
+ synchronize_rcu();
for (pg = tmp_page; pg; pg = tmp_page) {
/* Needs to be called outside of ftrace_lock */
@@ -7142,6 +7147,7 @@ void ftrace_free_mem(struct module *mod, void *start_ptr,
void *end_ptr)
unsigned long start = (unsigned long)(start_ptr);
unsigned long end = (unsigned long)(end_ptr);
struct ftrace_page **last_pg = _pages_start;
+ struct ftrace_page *tmp_page = NULL;
struct
Re: [PATCH v22 2/5] ring-buffer: Introducing ring-buffer mapping functions
On Tue, May 07, 2024 at 10:34:02PM -0400, Steven Rostedt wrote:
> On Tue, 30 Apr 2024 12:13:51 +0100
> Vincent Donnefort wrote:
>
> > +#ifdef CONFIG_MMU
> > +static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
> > + struct vm_area_struct *vma)
> > +{
> > + unsigned long nr_subbufs, nr_pages, vma_pages, pgoff = vma->vm_pgoff;
> > + unsigned int subbuf_pages, subbuf_order;
> > + struct page **pages;
> > + int p = 0, s = 0;
> > + int err;
> > +
> > + /* Refuse MP_PRIVATE or writable mappings */
> > + if (vma->vm_flags & VM_WRITE || vma->vm_flags & VM_EXEC ||
> > + !(vma->vm_flags & VM_MAYSHARE))
> > + return -EPERM;
> > +
> > + /*
> > +* Make sure the mapping cannot become writable later. Also tell the VM
> > +* to not touch these pages (VM_DONTCOPY | VM_DONTEXPAND). Finally,
> > +* prevent migration, GUP and dump (VM_IO).
> > +*/
> > + vm_flags_mod(vma, VM_DONTCOPY | VM_DONTEXPAND | VM_IO, VM_MAYWRITE);
>
> Do we really need the VM_IO?
>
> When testing this in gdb, I would get:
>
> (gdb) p tmap->map->subbuf_size
> Cannot access memory at address 0x77fc2008
>
> It appears that you can't ptrace IO memory. When I removed that flag,
> gdb has no problem reading that memory.
Yeah, VM_IO indeed implies DONTDUMP. VM_IO was part of Linus recommendations.
But perhaps, VM_DONTEXPAND and MIXEDMAP (implicitely set by vm_insert_pages) are
enough protection?
I don't see how anything could use GUP there and as David pointed-out on the
previous version, it doesn't event prevent the GUP-fast path.
>
> I think we should drop that flag.
>
> Can you send a v23 with that removed, Shuah's update, and also the
> change below:
Ack.
[...]
[PATCH v2] module: create weak dependecies
It has been seen that for some network mac drivers (i.e. lan78xx) the
related module for the phy is loaded dynamically depending on the current
hardware. In this case, the associated phy is read using mdio bus and then
the associated phy module is loaded during runtime (kernel function
phy_request_driver_module). However, no software dependency is defined, so
the user tools will no be able to get this dependency. For example, if
dracut is used and the hardware is present, lan78xx will be included but no
phy module will be added, and in the next restart the device will not work
from boot because no related phy will be found during initramfs stage.
In order to solve this, we could define a normal 'pre' software dependency
in lan78xx module with all the possible phy modules (there may be some),
but proceeding in that way, all the possible phy modules would be loaded
while only one is necessary.
The idea is to create a new type of dependency, that we are going to call
'weak' to be used only by the user tools that need to detect this situation.
In that way, for example, dracut could check the 'weak' dependency of the
modules involved in order to install these dependencies in initramfs too.
That is, for the commented lan78xx module, defining the 'weak' dependency
with the possible phy modules list, only the necessary phy would be loaded
on demand keeping the same behavior, but all the possible phy modules would
be available from initramfs.
The 'weak' dependency support has been included in kmod:
https://github.com/kmod-project/kmod/commit/05828b4a6e9327a63ef94df544a042b5e9ce4fe7
Signed-off-by: Jose Ignacio Tornos Martinez
---
V1 -> V2:
- Include reference to 'weak' dependency support in kmod.
include/linux/module.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/module.h b/include/linux/module.h
index 1153b0d99a80..231e710d8736 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -173,6 +173,11 @@ extern void cleanup_module(void);
*/
#define MODULE_SOFTDEP(_softdep) MODULE_INFO(softdep, _softdep)
+/* Weak module dependencies. See man modprobe.d for details.
+ * Example: MODULE_WEAKDEP("module-foo")
+ */
+#define MODULE_WEAKDEP(_weakdep) MODULE_INFO(weakdep, _weakdep)
+
/*
* MODULE_FILE is used for generating modules.builtin
* So, make it no-op when this is being built as a module
--
2.44.0
Re: [PATCHv5 bpf-next 6/8] x86/shstk: Add return uprobe support
On Tue, May 07, 2024 at 05:35:54PM +, Edgecombe, Rick P wrote: > On Tue, 2024-05-07 at 12:53 +0200, Jiri Olsa wrote: > > diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c > > index 81e6ee95784d..ae6c3458a675 100644 > > --- a/arch/x86/kernel/uprobes.c > > +++ b/arch/x86/kernel/uprobes.c > > @@ -406,6 +406,11 @@ SYSCALL_DEFINE0(uretprobe) > > * trampoline's ret instruction > > */ > > r11_cx_ax[2] = regs->ip; > > + > > + /* make the shadow stack follow that */ > > + if (shstk_push_frame(regs->ip)) > > + goto sigill; > > + > > regs->ip = ip; > > > > Per the earlier discussion, this cannot be reached unless uretprobes are in > use, > which cannot happen without something with privileges taking an action. But > are > uretprobes ever used for monitoring applications where security is important? > Or > is it strictly a debug-time thing? sorry, I don't have that level of detail, but we do have customers that use uprobes in general or want to use it and complain about the speed there are several tools in bcc [1] that use uretprobes in scripts, like: memleak, sslsniff, trace, bashreadline, gethostlatency, argdist, funclatency jirka [1] https://github.com/iovisor/bcc
general protection fault in crypto_skcipher_encrypt
Hello. We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue. Stack dump: bcachefs (loop0): error validating btree node on loop0 at btree extents level 0/0 u64s 11 type btree_ptr_v2 SPOS_MAX len 0 ver 0: seq 83426fcb67886cbe written 16 min_key POS_MIN durability: 1 ptr: 0:27:0 gen 0 node offset 0 bset u64s 0: unknown checksum type 4, fixing general protection fault, probably for non-canonical address 0xdc04: [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0020-0x0027] CPU: 0 PID: 25892 Comm: syz-executor.0 Not tainted 6.7.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:crypto_skcipher_alg include/crypto/skcipher.h:387 [inline] RIP: 0010:crypto_skcipher_encrypt+0x48/0x170 crypto/skcipher.c:656 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 17 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 40 48 8d 7b 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 08 01 00 00 48 8d 7b 04 4c 8b 63 18 48 b8 00 00 RSP: 0018:c90002d46388 EFLAGS: 00010202 RAX: dc00 RBX: 0008 RCX: c9000e04a000 RDX: 0004 RSI: 84162b50 RDI: 0020 RBP: c90002d463f8 R08: 0020 R09: 0001 R10: 0001 R11: R12: 0008 R13: 0020 R14: 88801133d600 R15: c90002d467d8 FS: 7fdd0174b640() GS:88802c60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 001b2df21000 CR3: 57314000 CR4: 00750ef0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Call Trace: do_encrypt_sg+0xbc/0x150 fs/bcachefs/checksum.c:107 do_encrypt+0x27d/0x430 fs/bcachefs/checksum.c:149 gen_poly_key.isra.0+0x144/0x310 fs/bcachefs/checksum.c:190 bch2_checksum+0x1bc/0x2b0 fs/bcachefs/checksum.c:226 bch2_btree_node_read_done+0x75b/0x45a0 fs/bcachefs/btree_io.c:1003 btree_node_read_work+0x77f/0x10e0 fs/bcachefs/btree_io.c:1262 bch2_btree_node_read+0xef3/0x1460 fs/bcachefs/btree_io.c:1641 __bch2_btree_root_read fs/bcachefs/btree_io.c:1680 [inline] bch2_btree_root_read+0x2bc/0x670 fs/bcachefs/btree_io.c:1704 read_btree_roots fs/bcachefs/recovery.c:384 [inline] bch2_fs_recovery+0x28b0/0x52d0 fs/bcachefs/recovery.c:914 bch2_fs_start+0x365/0x5e0 fs/bcachefs/super.c:978 bch2_fs_open+0x1ac9/0x3890 fs/bcachefs/super.c:1968 bch2_mount+0x538/0x13c0 fs/bcachefs/fs.c:1863 legacy_get_tree+0x109/0x220 fs/fs_context.c:662 vfs_get_tree+0x93/0x380 fs/super.c:1771 do_new_mount fs/namespace.c:3337 [inline] path_mount+0x679/0x1e40 fs/namespace.c:3664 do_mount fs/namespace.c:3677 [inline] __do_sys_mount fs/namespace.c:3886 [inline] __se_sys_mount fs/namespace.c:3863 [inline] __x64_sys_mount+0x287/0x310 fs/namespace.c:3863 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7fdd00a91b3e Code: 48 c7 c0 ff ff ff ff eb aa e8 be 0d 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7fdd0174ae38 EFLAGS: 0202 ORIG_RAX: 00a5 RAX: ffda RBX: 000119fc RCX: 7fdd00a91b3e RDX: 20011a00 RSI: 2040 RDI: 7fdd0174ae90 RBP: 7fdd0174aed0 R08: 7fdd0174aed0 R09: 0001 R10: 0001 R11: 0202 R12: 20011a00 R13: 2040 R14: 7fdd0174ae90 R15: 2100 Modules linked in: ---[ end trace ]--- RIP: 0010:crypto_skcipher_alg include/crypto/skcipher.h:387 [inline] RIP: 0010:crypto_skcipher_encrypt+0x48/0x170 crypto/skcipher.c:656 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 17 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 5d 40 48 8d 7b 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 08 01 00 00 48 8d 7b 04 4c 8b 63 18 48 b8 00 00 RSP: 0018:c90002d46388 EFLAGS: 00010202 RAX: dc00 RBX: 0008 RCX: c9000e04a000 RDX: 0004 RSI: 84162b50 RDI: 0020 RBP: c90002d463f8 R08: 0020 R09: 0001 R10: 0001 R11: R12: 0008 R13: 0020 R14: 88801133d600 R15: c90002d467d8 FS: 7fdd0174b640() GS:88802c60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 55e4cd278120 CR3: 57314000 CR4: 00750ef0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Code disassembly (best guess): 0: 48 89 fa
WARNING in fscrypt_fname_siphash
Hello. We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec. Recently, our team has discovered a issue in Linux kernel 6.7. Attached to the email were a PoC file of the issue. Stack dump: [ cut here ] WARNING: CPU: 0 PID: 10070 at fs/crypto/fname.c:573 fscrypt_fname_siphash+0xdf/0x120 fs/crypto/fname.c:573 Modules linked in: CPU: 0 PID: 10070 Comm: syz-executor.2 Not tainted 6.7.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fscrypt_fname_siphash+0xdf/0x120 fs/crypto/fname.c:573 Code: 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 80 3c 01 00 75 3f 48 8b 7b 08 48 83 c4 10 5b 5d 41 5c e9 d7 79 6e 08 e8 f2 a2 80 ff 90 <0f> 0b 90 eb 93 48 89 14 24 e8 b3 5b d7 ff 48 8b 14 24 eb b7 e8 48 RSP: 0018:c90002887238 EFLAGS: 00010246 RAX: 0004 RBX: c900028872d0 RCX: c900030cb000 RDX: 0004 RSI: 8209535e RDI: 0001 RBP: 888063065180 R08: 0001 R09: R10: R11: 8d4c4d91 R12: R13: 0001 R14: dc00 R15: 888056aba0c4 FS: 7ff63b86f640() GS:88802c60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7ff5442398e0 CR3: 57fd8000 CR4: 00750ef0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 PKRU: 5554 Call Trace: __ext4fs_dirhash+0x36a/0xb60 fs/ext4/hash.c:268 ext4fs_dirhash+0x246/0x2d0 fs/ext4/hash.c:322 htree_dirblock_to_tree+0x821/0xc90 fs/ext4/namei.c:1124 ext4_htree_fill_tree+0x32d/0xc40 fs/ext4/namei.c:1219 ext4_dx_readdir fs/ext4/dir.c:597 [inline] ext4_readdir+0x1d2d/0x36a0 fs/ext4/dir.c:142 iterate_dir+0x1f4/0x5c0 fs/readdir.c:106 ovl_dir_read fs/overlayfs/readdir.c:315 [inline] ovl_indexdir_cleanup+0x2e2/0x940 fs/overlayfs/readdir.c:1183 ovl_get_indexdir fs/overlayfs/super.c:887 [inline] ovl_fill_super+0x414d/0x6560 fs/overlayfs/super.c:1404 vfs_get_super fs/super.c:1338 [inline] get_tree_nodev+0xda/0x190 fs/super.c:1357 vfs_get_tree+0x93/0x380 fs/super.c:1771 do_new_mount fs/namespace.c:3337 [inline] path_mount+0x679/0x1e40 fs/namespace.c:3664 do_mount fs/namespace.c:3677 [inline] __do_sys_mount fs/namespace.c:3886 [inline] __se_sys_mount fs/namespace.c:3863 [inline] __x64_sys_mount+0x287/0x310 fs/namespace.c:3863 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x43/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7ff63aa8fd6d Code: c3 e8 97 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7ff63b86f028 EFLAGS: 0246 ORIG_RAX: 00a5 RAX: ffda RBX: 7ff63abcc120 RCX: 7ff63aa8fd6d RDX: 2000 RSI: 2040 RDI: RBP: 7ff63aaf14cd R08: 2140 R09: R10: R11: 0246 R12: R13: 006e R14: 7ff63abcc120 R15: 7ff63b84f000 Thank you for taking the time to read this email and we look forward to working with you further. poc.c Description: Binary data
