Hi All,
Chages since v3:
- pfn_to_virt() changed to page_to_virt() due to compile error
Chages since v2:
- page allocation moved out of the atomic context
Chages since v1:
- Fixes: and -stable tags added to the patch description
Thanks!
Alexander Gordeev (1):
kasan: Avoid sleepable page allocation from atomic context
mm/kasan/shadow.c | 63 +++++++++++++++++++++++++++++++++++------------
1 file changed, 47 insertions(+), 16 deletions(-)
--
2.45.2
Hi All,
Chages since v2:
- page allocation moved out of the atomic context
Chages since v1:
- Fixes: and -stable tags added to the patch description
Thanks!
Alexander Gordeev (1):
kasan: Avoid sleepable page allocation from atomic context
mm/kasan/shadow.c | 65 +++++++++++++++++++++++++++++++++++------------
1 file changed, 49 insertions(+), 16 deletions(-)
--
2.45.2
Greetings Dear,
Send your Ref: FSG2025 / Name / Phone Number / Country to Mr. Andrej
Mahecic on un.grant(a)socialworker.net, +1 888 673 0430 for your £100,000.00.
Sincerely
Mr. C. Gunness
On behalf of the UN.
From: Daniel Gomez <da.gomez(a)samsung.com>
[ Upstream commit a26fe287eed112b4e21e854f173c8918a6a8596d ]
The scripts/kconfig/merge_config.sh script requires an existing
$INITFILE (or the $1 argument) as a base file for merging Kconfig
fragments. However, an empty $INITFILE can serve as an initial starting
point, later referenced by the KCONFIG_ALLCONFIG Makefile variable
if -m is not used. This variable can point to any configuration file
containing preset config symbols (the merged output) as stated in
Documentation/kbuild/kconfig.rst. When -m is used $INITFILE will
contain just the merge output requiring the user to run make (i.e.
KCONFIG_ALLCONFIG=<$INITFILE> make <allnoconfig/alldefconfig> or make
olddefconfig).
Instead of failing when `$INITFILE` is missing, create an empty file and
use it as the starting point for merges.
Signed-off-by: Daniel Gomez <da.gomez(a)samsung.com>
Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
scripts/kconfig/merge_config.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/merge_config.sh b/scripts/kconfig/merge_config.sh
index 0b7952471c18f..79c09b378be81 100755
--- a/scripts/kconfig/merge_config.sh
+++ b/scripts/kconfig/merge_config.sh
@@ -112,8 +112,8 @@ INITFILE=$1
shift;
if [ ! -r "$INITFILE" ]; then
- echo "The base file '$INITFILE' does not exist. Exit." >&2
- exit 1
+ echo "The base file '$INITFILE' does not exist. Creating one..." >&2
+ touch "$INITFILE"
fi
MERGE_LIST=$*
--
2.39.5
On configs with CONFIG_ARM64_GCS=y, VM_SHADOW_STACK is bit 38.
On configs with CONFIG_HAVE_ARCH_USERFAULTFD_MINOR=y (selected by
CONFIG_ARM64 when CONFIG_USERFAULTFD=y), VM_UFFD_MINOR is _also_ bit 38.
This bit being shared by two different VMA flags could lead to all sorts
of unintended behaviors. Presumably, a process could maybe call into
userfaultfd in a way that disables the shadow stack vma flag. I can't
think of any attack where this would help (presumably, if an attacker
tries to disable shadow stacks, they are trying to hijack control flow
so can't arbitrarily call into userfaultfd yet anyway) but this still
feels somewhat scary.
Fixes: ae80e1629aea ("mm: Define VM_SHADOW_STACK for arm64 when we support GCS")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Florent Revest <revest(a)chromium.org>
---
include/linux/mm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index bf55206935c46..fdda6b16263b3 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -385,7 +385,7 @@ extern unsigned int kobjsize(const void *objp);
#endif
#ifdef CONFIG_HAVE_ARCH_USERFAULTFD_MINOR
-# define VM_UFFD_MINOR_BIT 38
+# define VM_UFFD_MINOR_BIT 41
# define VM_UFFD_MINOR BIT(VM_UFFD_MINOR_BIT) /* UFFD minor faults */
#else /* !CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
# define VM_UFFD_MINOR VM_NONE
--
2.49.0.967.g6a0df3ecc3-goog
From: Amit Sunil Dhamne <amitsd(a)google.com>
Register read of TCPC_RX_BYTE_CNT returns the total size consisting of:
PD message (pending read) size + 1 Byte for Frame Type (SOP*)
This is validated against the max PD message (`struct pd_message`) size
without accounting for the extra byte for the frame type. Note that the
struct pd_message does not contain a field for the frame_type. This
results in false negatives when the "PD message (pending read)" is equal
to the max PD message size.
Fixes: 6f413b559f86 ("usb: typec: tcpci_maxim: Chip level TCPC driver")
Signed-off-by: Amit Sunil Dhamne <amitsd(a)google.com>
Signed-off-by: Badhri Jagan Sridharan <badhri(a)google.com>
Reviewed-by: Kyle Tso <kyletso(a)google.com>
---
drivers/usb/typec/tcpm/tcpci_maxim_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/tcpm/tcpci_maxim_core.c b/drivers/usb/typec/tcpm/tcpci_maxim_core.c
index fd1b80593367641a6f997da2fb97a2b7238f6982..648311f5e3cf135f23b5cc0668001d2f177b9edd 100644
--- a/drivers/usb/typec/tcpm/tcpci_maxim_core.c
+++ b/drivers/usb/typec/tcpm/tcpci_maxim_core.c
@@ -166,7 +166,8 @@ static void process_rx(struct max_tcpci_chip *chip, u16 status)
return;
}
- if (count > sizeof(struct pd_message) || count + 1 > TCPC_RECEIVE_BUFFER_LEN) {
+ if (count > sizeof(struct pd_message) + 1 ||
+ count + 1 > TCPC_RECEIVE_BUFFER_LEN) {
dev_err(chip->dev, "Invalid TCPC_RX_BYTE_CNT %d\n", count);
return;
}
---
base-commit: ebd297a2affadb6f6f4d2e5d975c1eda18ac762d
change-id: 20250421-b4-new-fix-pd-rx-count-79297ba619b7
Best regards,
--
Amit Sunil Dhamne <amitsd(a)google.com>
create_init_idmap() could be called before .bss section initialization
which is done in early_map_kernel().
Therefore, data/test_prot could be set incorrectly by PTE_MAYBE_NG macro.
PTE_MAYBE_NG macro set NG bit according to value of "arm64_use_ng_mappings".
and this variable places in .bss section.
# llvm-objdump-21 --syms vmlinux-gcc | grep arm64_use_ng_mappings
ffff800082f242a8 g O .bss 0000000000000001 arm64_use_ng_mappings
If .bss section doesn't initialized, "arm64_use_ng_mappings" would be set
with garbage value and then the text_prot or data_prot could be set incorrectly.
Here is what i saw with kernel compiled via llvm-21
// create_init_idmap()
ffff80008255c058: d10103ff sub sp, sp, #0x40
ffff80008255c05c: a9017bfd stp x29, x30, [sp, #0x10]
ffff80008255c060: a90257f6 stp x22, x21, [sp, #0x20]
ffff80008255c064: a9034ff4 stp x20, x19, [sp, #0x30]
ffff80008255c068: 910043fd add x29, sp, #0x10
ffff80008255c06c: 90003fc8 adrp x8, 0xffff800082d54000
ffff80008255c070: d280e06a mov x10, #0x703 // =1795
ffff80008255c074: 91400409 add x9, x0, #0x1, lsl #12 // =0x1000
ffff80008255c078: 394a4108 ldrb w8, [x8, #0x290] ------------- (1)
ffff80008255c07c: f2e00d0a movk x10, #0x68, lsl #48
ffff80008255c080: f90007e9 str x9, [sp, #0x8]
ffff80008255c084: aa0103f3 mov x19, x1
ffff80008255c088: aa0003f4 mov x20, x0
ffff80008255c08c: 14000000 b 0xffff80008255c08c <__pi_create_init_idmap+0x34>
ffff80008255c090: aa082d56 orr x22, x10, x8, lsl #11 -------- (2)
Note, (1) is load the arm64_use_ng_mappings value in w8 and
(2) is set the text or data prot with the w8 value to set PTE_NG bit.
If .bss section doesn't initialized, x8 can include garbage value
-- In case of some platform, x8 loaded with 0xcf -- it could generate
wrong mapping. (i.e) text_prot is expected with
PAGE_KERNEL_ROX(0x0040000000000F83) but
with garbage x8 -- 0xcf, it sets with (0x0040000000067F83)
and This makes boot failure with translation fault.
This error cannot happen according to code generated by compiler.
here is the case of gcc:
ffff80008260a940 <__pi_create_init_idmap>:
ffff80008260a940: d100c3ff sub sp, sp, #0x30
ffff80008260a944: aa0003ed mov x13, x0
ffff80008260a948: 91400400 add x0, x0, #0x1, lsl #12 // =0x1000
ffff80008260a94c: a9017bfd stp x29, x30, [sp, #0x10]
ffff80008260a950: 910043fd add x29, sp, #0x10
ffff80008260a954: f90017e0 str x0, [sp, #0x28]
ffff80008260a958: d00048c0 adrp x0, 0xffff800082f24000 <reset_devices>
ffff80008260a95c: 394aa000 ldrb w0, [x0, #0x2a8]
ffff80008260a960: 37000640 tbnz w0, #0x0, 0xffff80008260aa28 <__pi_create_init_idmap+0xe8> ---(3)
ffff80008260a964: d280f060 mov x0, #0x783 // =1923
ffff80008260a968: d280e062 mov x2, #0x703 // =1795
ffff80008260a96c: f2e00800 movk x0, #0x40, lsl #48
ffff80008260a970: f2e00d02 movk x2, #0x68, lsl #48
ffff80008260a974: aa2103e4 mvn x4, x1
ffff80008260a978: 8a210049 bic x9, x2, x1
...
ffff80008260aa28: d281f060 mov x0, #0xf83 // =3971
ffff80008260aa2c: d281e062 mov x2, #0xf03 // =3843
ffff80008260aa30: f2e00800 movk x0, #0x40, lsl #48
In case of gcc, according to value of arm64_use_ng_mappings (annoated as(3)),
it branches to each prot settup code.
However this is also problem since it branches according to garbage
value too -- idmapping with incorrect pgprot.
To resolve this, annotate arm64_use_ng_mappings as ro_after_init.
Fixes: 84b04d3e6bdb ("arm64: kernel: Create initial ID map from C code")
Cc: <stable(a)vger.kernel.org> # 6.9.x
Tested-by: Nathan Chancellor <nathan(a)kernel.org>
Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com>
---
Since v1:
- add comments explaining arm64_use_ng_mappings shouldn't place .bss
section
- fix type on commit message
- https://lore.kernel.org/all/20250502145755.3751405-1-yeoreum.yun@arm.com/
There is another way to solve this problem by setting
test/data_prot with _PAGE_DEFAULT which doesn't include PTE_MAYBE_NG
with constanst check in create_init_idmap() to be free from
arm64_use_ng_mappings. but i think it would be better to change
arm64_use_ng_mappings as ro_after_init because it doesn't change after
init phase and solve this problem too.
---
arch/arm64/kernel/cpufeature.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d2104a1e7843..913ae2cead98 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -114,7 +114,18 @@ static struct arm64_cpu_capabilities const __ro_after_init *cpucap_ptrs[ARM64_NC
DECLARE_BITMAP(boot_cpucaps, ARM64_NCAPS);
-bool arm64_use_ng_mappings = false;
+/*
+ * The variable arm64_use_ng_mappings should be placed in the .rodata section.
+ * Otherwise, it would end up in the .bss section, where it is initialized in
+ * early_map_kernel(). This can cause problems because the PTE_MAYBE_NG macro
+ * uses this variable, and create_init_idmap() — which might run before
+ * early_map_kernel() — could end up generating an incorrect idmap table.
+ *
+ * In other words, accessing variable placed in .bss section before
+ * early_map_kernel() will return garbage,
+ * potentially resulting in a wrong pgprot value.
+ */
+bool arm64_use_ng_mappings __ro_after_init = false;
EXPORT_SYMBOL(arm64_use_ng_mappings);
DEFINE_PER_CPU_READ_MOSTLY(const char *, this_cpu_vector) = vectors;
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}