[PATCH 0/5] riscv: Assorted bug fixes

[PATCH 0/5] riscv: Assorted bug fixes

[Michael Neuling]

This series contains five independent bug fixes across the RISC-V
architecture code, found with the help of Claude AI (claude-4.6-opus):

  1. riscv: errata: Fix bitwise vs logical AND in MIPS errata patching
     - Logical AND (&&) was used instead of bitwise AND (&) when checking
       errata flags, causing all errata patches to be applied when any
       single one was detected.

  2. riscv: ptrace: Fix register corruption in compat_riscv_gpr_set on error
     - On copyin failure, uninitialized stack data was written into the
       target task's pt_regs, corrupting registers and potentially
       leaking kernel stack contents.

  3. riscv: mm: Fix NULL pointer dereference in __set_memory
     - find_vm_area() can return NULL but was dereferenced without a check.

  4. riscv: mm: Fix NULL dereferences in napot hugetlb functions
     - huge_pte_offset() can return NULL in the napot path but was used
       without NULL checks in huge_ptep_set_access_flags() and
       huge_ptep_set_wrprotect().

  5. riscv: mm: Fix TOCTOU race in remove_pte_mapping
     - The PTE was read twice (once via ptep_get, once via *ptep),
       creating a race window where another CPU could modify the PTE
       between reads.

All patches are small and self-contained. These bugs were identified
through AI-assisted code review using Claude, which also assisted in
writing the fixes. Each patch has been manually reviewed for correctness.

Michael Neuling (5):
  riscv: errata: Fix bitwise vs logical AND in MIPS errata patching
  riscv: ptrace: Fix register corruption in compat_riscv_gpr_set on
    error
  riscv: mm: Fix NULL pointer dereference in __set_memory
  riscv: mm: Fix NULL dereferences in napot hugetlb functions
  riscv: mm: Fix TOCTOU race in remove_pte_mapping

 arch/riscv/errata/mips/errata.c | 2 +-
 arch/riscv/kernel/ptrace.c      | 4 ++--
 arch/riscv/mm/hugetlbpage.c     | 4 ++++
 arch/riscv/mm/init.c            | 2 +-
 arch/riscv/mm/pageattr.c        | 4 ++++
 5 files changed, 12 insertions(+), 4 deletions(-)

-- 
2.43.0

[PATCH 1/5] riscv: errata: Fix bitwise vs logical AND in MIPS errata patching

[Michael Neuling]

The condition checking whether a specific errata needs patching uses
logical AND (&&) instead of bitwise AND (&). Since logical AND only
checks that both operands are non-zero, this causes all errata patches
to be applied whenever any single errata is detected, rather than only
applying the matching one.

The SiFive errata implementation correctly uses bitwise AND for the same
check.

Fixes: 0b0ca959d2 ("riscv: errata: Fix the PAUSE Opcode for MIPS P8700")
Signed-off-by: Michael Neuling <mikey@neuling.org>
Assisted-by: Cursor:claude-4.6-opus-high-thinking
---
 arch/riscv/errata/mips/errata.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/errata/mips/errata.c b/arch/riscv/errata/mips/errata.c
index e984a81522..2c3dc2259e 100644
--- a/arch/riscv/errata/mips/errata.c
+++ b/arch/riscv/errata/mips/errata.c
@@ -57,7 +57,7 @@ void mips_errata_patch_func(struct alt_entry *begin, struct alt_entry *end,
 		}
 
 		tmp = (1U << alt->patch_id);
-		if (cpu_req_errata && tmp) {
+		if (cpu_req_errata & tmp) {
 			mutex_lock(&text_mutex);
 			patch_text_nosync(ALT_OLD_PTR(alt), ALT_ALT_PTR(alt),
 					  alt->alt_len);
-- 
2.43.0

[PATCH 2/5] riscv: ptrace: Fix register corruption in compat_riscv_gpr_set on error

[Michael Neuling]

compat_riscv_gpr_set() calls cregs_to_regs() unconditionally, even when
user_regset_copyin() fails. Since cregs is an uninitialized stack
variable, a copyin failure causes uninitialized stack data to be written
into the target task's pt_regs, corrupting its register state and
potentially leaking kernel stack contents.

Only call cregs_to_regs() when user_regset_copyin() succeeds.

Fixes: 4608c15959 ("riscv: compat: ptrace: Add compat_arch_ptrace implement")
Signed-off-by: Michael Neuling <mikey@neuling.org>
Assisted-by: Cursor:claude-4.6-opus-high-thinking
---
 arch/riscv/kernel/ptrace.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index 93de2e7a30..793bcee461 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch/riscv/kernel/ptrace.c
@@ -577,8 +577,8 @@ static int compat_riscv_gpr_set(struct task_struct *target,
 	struct compat_user_regs_struct cregs;
 
 	ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, &cregs, 0, -1);
-
-	cregs_to_regs(&cregs, task_pt_regs(target));
+	if (!ret)
+		cregs_to_regs(&cregs, task_pt_regs(target));
 
 	return ret;
 }
-- 
2.43.0

[PATCH 3/5] riscv: mm: Fix NULL pointer dereference in __set_memory

[Michael Neuling]

find_vm_area() can return NULL if no vm_struct covers the given address.
The code immediately dereferences area->addr without a NULL check.
While is_vmalloc_or_module_addr() confirms the address falls within the
vmalloc/module address range, it does not guarantee the address belongs
to an active allocation, so find_vm_area() may still return NULL.

Add the missing NULL check.

Fixes: 311cd2f6e2 ("riscv: Fix set_memory_XX() and set_direct_map_XX() by splitting huge linear mappings")
Signed-off-by: Michael Neuling <mikey@neuling.org>
Assisted-by: Cursor:claude-4.6-opus-high-thinking
---
 arch/riscv/mm/pageattr.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/mm/pageattr.c b/arch/riscv/mm/pageattr.c
index 3f76db3d27..46a999c86b 100644
--- a/arch/riscv/mm/pageattr.c
+++ b/arch/riscv/mm/pageattr.c
@@ -289,6 +289,10 @@ static int __set_memory(unsigned long addr, int numpages, pgprot_t set_mask,
 		int i, page_start;
 
 		area = find_vm_area((void *)start);
+		if (!area) {
+			ret = -EINVAL;
+			goto unlock;
+		}
 		page_start = (start - (unsigned long)area->addr) >> PAGE_SHIFT;
 
 		for (i = page_start; i < page_start + numpages; ++i) {
-- 
2.43.0

[PATCH 4/5] riscv: mm: Fix NULL dereferences in napot hugetlb functions

[Michael Neuling]

huge_pte_offset() can return NULL when any level of the page table walk
encounters a non-present entry. Both huge_ptep_set_access_flags() and
huge_ptep_set_wrprotect() re-derive ptep via huge_pte_offset() in the
napot path but use the result without a NULL check, leading to NULL
pointer dereferences in get_clear_contig_flush() and set_pte_at().

Add NULL checks after huge_pte_offset() in both functions.

Fixes: 82a1a1f3bf ("riscv: mm: support Svnapot in hugetlb page")
Signed-off-by: Michael Neuling <mikey@neuling.org>
Assisted-by: Cursor:claude-4.6-opus-high-thinking
---
 arch/riscv/mm/hugetlbpage.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c
index a6d217112c..7d155341cf 100644
--- a/arch/riscv/mm/hugetlbpage.c
+++ b/arch/riscv/mm/hugetlbpage.c
@@ -288,6 +288,8 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
 	order = napot_cont_order(pte);
 	pte_num = napot_pte_num(order);
 	ptep = huge_pte_offset(mm, addr, napot_cont_size(order));
+	if (!ptep)
+		return 0;
 	orig_pte = get_clear_contig_flush(mm, addr, ptep, pte_num);
 
 	if (pte_dirty(orig_pte))
@@ -335,6 +337,8 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
 	order = napot_cont_order(pte);
 	pte_num = napot_pte_num(order);
 	ptep = huge_pte_offset(mm, addr, napot_cont_size(order));
+	if (!ptep)
+		return;
 	orig_pte = get_clear_contig_flush(mm, addr, ptep, pte_num);
 
 	orig_pte = pte_wrprotect(orig_pte);
-- 
2.43.0

[PATCH 5/5] riscv: mm: Fix TOCTOU race in remove_pte_mapping

[Michael Neuling]

remove_pte_mapping() reads the PTE via ptep_get() (a READ_ONCE) into a
local variable, but then checks pte_present(*ptep) by dereferencing the
pointer directly, reading the PTE a second time. If another CPU modifies
the PTE between the two reads, pte_present may check a different value
than what was captured, and the subsequent pte_page() could derive the
wrong page to free.

Use the already-captured local pte variable for the pte_present check.

Fixes: c75a74f4ba ("riscv: mm: Add memory hotplugging support")
Signed-off-by: Michael Neuling <mikey@neuling.org>
Assisted-by: Cursor:claude-4.6-opus-high-thinking
---
 arch/riscv/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 23cc1b81fa..873cc860a1 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -1562,7 +1562,7 @@ static void __meminit remove_pte_mapping(pte_t *pte_base, unsigned long addr, un
 
 		ptep = pte_base + pte_index(addr);
 		pte = ptep_get(ptep);
-		if (!pte_present(*ptep))
+		if (!pte_present(pte))
 			continue;
 
 		pte_clear(&init_mm, addr, ptep);
-- 
2.43.0

Re: [PATCH 5/5] riscv: mm: Fix TOCTOU race in remove_pte_mapping

[David Hildenbrand (Arm)]

On 4/9/26 11:11, Michael Neuling wrote:
> remove_pte_mapping() reads the PTE via ptep_get() (a READ_ONCE) into a
> local variable, but then checks pte_present(*ptep) by dereferencing the
> pointer directly, reading the PTE a second time. If another CPU modifies
> the PTE between the two reads
Is that even possible?

The code does not use any locking, so nothing would be safe here if
races could happen, no?

-- 
Cheers,

David

Re: [PATCH 4/5] riscv: mm: Fix NULL dereferences in napot hugetlb functions

[David Hildenbrand (Arm)]

On 4/9/26 11:11, Michael Neuling wrote:
> huge_pte_offset() can return NULL when any level of the page table walk
> encounters a non-present entry. Both huge_ptep_set_access_flags() and
> huge_ptep_set_wrprotect() re-derive ptep via huge_pte_offset() in the
> napot path but use the result without a NULL check, leading to NULL
> pointer dereferences in get_clear_contig_flush() and set_pte_at().
> 
> Add NULL checks after huge_pte_offset() in both functions.
> 
> Fixes: 82a1a1f3bf ("riscv: mm: support Svnapot in hugetlb page")
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Assisted-by: Cursor:claude-4.6-opus-high-thinking
> ---
>  arch/riscv/mm/hugetlbpage.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c
> index a6d217112c..7d155341cf 100644
> --- a/arch/riscv/mm/hugetlbpage.c
> +++ b/arch/riscv/mm/hugetlbpage.c
> @@ -288,6 +288,8 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
>  	order = napot_cont_order(pte);
>  	pte_num = napot_pte_num(order);
>  	ptep = huge_pte_offset(mm, addr, napot_cont_size(order));
> +	if (!ptep)
> +		return 0;
>  	orig_pte = get_clear_contig_flush(mm, addr, ptep, pte_num);
>  
>  	if (pte_dirty(orig_pte))
> @@ -335,6 +337,8 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
>  	order = napot_cont_order(pte);
>  	pte_num = napot_pte_num(order);
>  	ptep = huge_pte_offset(mm, addr, napot_cont_size(order));
> +	if (!ptep)
> +		return;
>  	orig_pte = get_clear_contig_flush(mm, addr, ptep, pte_num);
>  
>  	orig_pte = pte_wrprotect(orig_pte);


These functions are called when we previously verified that there is
indeed a pte mapped. And while holding the PTL to protect concurrent
unmapping.

So how should this possibly trigger?

-- 
Cheers,

David

Re: [PATCH 3/5] riscv: mm: Fix NULL pointer dereference in __set_memory

[David Hildenbrand (Arm)]

On 4/9/26 11:11, Michael Neuling wrote:
> find_vm_area() can return NULL if no vm_struct covers the given address.
> The code immediately dereferences area->addr without a NULL check.
> While is_vmalloc_or_module_addr() confirms the address falls within the
> vmalloc/module address range, it does not guarantee the address belongs
> to an active allocation, so find_vm_area() may still return NULL.
> 
> Add the missing NULL check.
> 
> Fixes: 311cd2f6e2 ("riscv: Fix set_memory_XX() and set_direct_map_XX() by splitting huge linear mappings")
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Assisted-by: Cursor:claude-4.6-opus-high-thinking
> ---
>  arch/riscv/mm/pageattr.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/riscv/mm/pageattr.c b/arch/riscv/mm/pageattr.c
> index 3f76db3d27..46a999c86b 100644
> --- a/arch/riscv/mm/pageattr.c
> +++ b/arch/riscv/mm/pageattr.c
> @@ -289,6 +289,10 @@ static int __set_memory(unsigned long addr, int numpages, pgprot_t set_mask,
>  		int i, page_start;
>  
>  		area = find_vm_area((void *)start);
> +		if (!area) {
> +			ret = -EINVAL;
> +			goto unlock;
> +		}
>  		page_start = (start - (unsigned long)area->addr) >> PAGE_SHIFT;
>  
>  		for (i = page_start; i < page_start + numpages; ++i) {

Which caller would end up calling __set_memory() in such a way?

-- 
Cheers,

David

Re: [PATCH 3/5] riscv: mm: Fix NULL pointer dereference in __set_memory

[Michael Neuling]

> >               area = find_vm_area((void *)start);
> > +             if (!area) {
> > +                     ret = -EINVAL;
> > +                     goto unlock;
> > +             }
> >               page_start = (start - (unsigned long)area->addr) >> PAGE_SHIFT;
> >
> >               for (i = page_start; i < page_start + numpages; ++i) {
>
> Which caller would end up calling __set_memory() in such a way?

It wouldn't. You're right on this and the other two. Sorry for the noise.

Mikey

Re: [PATCH 3/5] riscv: mm: Fix NULL pointer dereference in __set_memory

[David Hildenbrand (Arm)]

On 4/10/26 08:23, Michael Neuling wrote:
>>>               area = find_vm_area((void *)start);
>>> +             if (!area) {
>>> +                     ret = -EINVAL;
>>> +                     goto unlock;
>>> +             }
>>>               page_start = (start - (unsigned long)area->addr) >> PAGE_SHIFT;
>>>
>>>               for (i = page_start; i < page_start + numpages; ++i) {
>>
>> Which caller would end up calling __set_memory() in such a way?
> 
> It wouldn't. You're right on this and the other two. Sorry for the noise.

Slopped-by: Cursor:claude-4.6-opus-high-thinking

:)

Patch #1 seems reasonable (although non-critical); not sure about patch
#2, leaving both to Risc-V people!

-- 
Cheers,

David

Re: [PATCH 3/5] riscv: mm: Fix NULL pointer dereference in __set_memory

[Mike Rapoport]

On Fri, Apr 10, 2026 at 09:42:26AM +0200, David Hildenbrand (Arm) wrote:
> On 4/10/26 08:23, Michael Neuling wrote:
> >>>               area = find_vm_area((void *)start);
> >>> +             if (!area) {
> >>> +                     ret = -EINVAL;
> >>> +                     goto unlock;
> >>> +             }
> >>>               page_start = (start - (unsigned long)area->addr) >> PAGE_SHIFT;
> >>>
> >>>               for (i = page_start; i < page_start + numpages; ++i) {
> >>
> >> Which caller would end up calling __set_memory() in such a way?
> > 
> > It wouldn't. You're right on this and the other two. Sorry for the noise.
> 
> Slopped-by: Cursor:claude-4.6-opus-high-thinking
> 
> :)

It's a general tendency of LLMs to generate overly defensive code and raise
concerns about theoretical issues.
Maybe it's worth taking into account when writing prompts specific to
kernel development.
 
> Patch #1 seems reasonable (although non-critical); not sure about patch
> #2, leaving both to Risc-V people!
> 
> -- 
> Cheers,
> 
> David

-- 
Sincerely yours,
Mike.

Re: [PATCH 3/5] riscv: mm: Fix NULL pointer dereference in __set_memory

[David Hildenbrand (Arm)]

On 4/10/26 09:53, Mike Rapoport wrote:
> On Fri, Apr 10, 2026 at 09:42:26AM +0200, David Hildenbrand (Arm) wrote:
>> On 4/10/26 08:23, Michael Neuling wrote:
>>>
>>> It wouldn't. You're right on this and the other two. Sorry for the noise.
>>
>> Slopped-by: Cursor:claude-4.6-opus-high-thinking
>>
>> :)
> 
> It's a general tendency of LLMs to generate overly defensive code and raise
> concerns about theoretical issues.
> Maybe it's worth taking into account when writing prompts specific to
> kernel development.

Yes, and I can only urge people to actually check what the LLM spits
out, so they won't lose their credibility with maintainers ;)

-- 
Cheers,

David

Re: [PATCH 3/5] riscv: mm: Fix NULL pointer dereference in __set_memory

[Michael Neuling]

On Fri, Apr 10, 2026 at 5:59 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 4/10/26 09:53, Mike Rapoport wrote:
> > On Fri, Apr 10, 2026 at 09:42:26AM +0200, David Hildenbrand (Arm) wrote:
> >> On 4/10/26 08:23, Michael Neuling wrote:
> >>>
> >>> It wouldn't. You're right on this and the other two. Sorry for the noise.
> >>
> >> Slopped-by: Cursor:claude-4.6-opus-high-thinking
> >>
> >> :)
> >
> > It's a general tendency of LLMs to generate overly defensive code and raise
> > concerns about theoretical issues.
> > Maybe it's worth taking into account when writing prompts specific to
> > kernel development.

We've had some success using it to review some patches for maintainers.

I was attempting to use it on existing code but I agree this was
overly defensive
and didn't consider the broader context.

> Yes, and I can only urge people to actually check what the LLM spits
> out, so they won't lose their credibility with maintainers ;)

I did actually dismiss more than half of what it produced. Maybe that makes
it worse :-)

I'm not as familiar with mm so it was a mistake on my part to send these.

Mikey