Linux 6.12.99

Linux 6.12.99

[Greg Kroah-Hartman]

I'm announcing the release of the 6.12.99 kernel.

All users of the 6.12 kernel series must upgrade.

The updated 6.12.y git tree can be found at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-6.12.y
and can be browsed at the normal kernel.org git web browser:
	https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h

------------

 Makefile               |    2 +-
 fs/proc/base.c         |   26 ++++++++++++++------------
 kernel/fork.c          |    5 +++--
 mm/madvise.c           |    4 ++--
 mm/process_vm_access.c |    4 ++--
 5 files changed, 22 insertions(+), 19 deletions(-)

Greg Kroah-Hartman (1):
      Linux 6.12.99

Lorenzo Stoakes (1):
      mm: refactor mm_access() to not return NULL

Re: Linux 6.12.99

[Greg Kroah-Hartman]

diff --git a/Makefile b/Makefile
index 671079b33674..a5fb7f21c310 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 6
 PATCHLEVEL = 12
-SUBLEVEL = 98
+SUBLEVEL = 99
 EXTRAVERSION =
 NAME = Baby Opossum Posse
 
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 9f0322368497..427fb5abb07c 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -817,19 +817,21 @@ static const struct file_operations proc_single_file_operations = {
 struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode)
 {
 	struct task_struct *task = get_proc_task(inode);
-	struct mm_struct *mm = ERR_PTR(-ESRCH);
+	struct mm_struct *mm;
 
-	if (task) {
-		mm = mm_access(task, mode | PTRACE_MODE_FSCREDS);
-		put_task_struct(task);
+	if (!task)
+		return ERR_PTR(-ESRCH);
 
-		if (!IS_ERR_OR_NULL(mm)) {
-			/* ensure this mm_struct can't be freed */
-			mmgrab(mm);
-			/* but do not pin its memory */
-			mmput(mm);
-		}
-	}
+	mm = mm_access(task, mode | PTRACE_MODE_FSCREDS);
+	put_task_struct(task);
+
+	if (IS_ERR(mm))
+		return mm == ERR_PTR(-ESRCH) ? NULL : mm;
+
+	/* ensure this mm_struct can't be freed */
+	mmgrab(mm);
+	/* but do not pin its memory */
+	mmput(mm);
 
 	return mm;
 }
@@ -2199,7 +2201,7 @@ static int map_files_d_revalidate(struct dentry *dentry, unsigned int flags)
 		goto out_notask;
 
 	mm = mm_access(task, PTRACE_MODE_READ_FSCREDS);
-	if (IS_ERR_OR_NULL(mm))
+	if (IS_ERR(mm))
 		goto out;
 
 	if (!dname_to_vma_addr(dentry, &vm_start, &vm_end)) {
diff --git a/kernel/fork.c b/kernel/fork.c
index 6191f1f8bde8..2b7577edffa2 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1580,8 +1580,9 @@ struct mm_struct *mm_access(struct task_struct *task, unsigned int mode)
 		return ERR_PTR(err);
 
 	mm = get_task_mm(task);
-	if (mm && mm != current->mm &&
-			!ptrace_may_access(task, mode)) {
+	if (!mm) {
+		mm = ERR_PTR(-ESRCH);
+	} else if (mm != current->mm && !ptrace_may_access(task, mode)) {
 		mmput(mm);
 		mm = ERR_PTR(-EACCES);
 	}
diff --git a/mm/madvise.c b/mm/madvise.c
index 4a3b609a33e6..d2b315993a1c 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -1521,8 +1521,8 @@ SYSCALL_DEFINE5(process_madvise, int, pidfd, const struct iovec __user *, vec,
 
 	/* Require PTRACE_MODE_READ to avoid leaking ASLR metadata. */
 	mm = mm_access(task, PTRACE_MODE_READ_FSCREDS);
-	if (IS_ERR_OR_NULL(mm)) {
-		ret = IS_ERR(mm) ? PTR_ERR(mm) : -ESRCH;
+	if (IS_ERR(mm)) {
+		ret = PTR_ERR(mm);
 		goto release_task;
 	}
 
diff --git a/mm/process_vm_access.c b/mm/process_vm_access.c
index b308e96cd05a..656d3e88755b 100644
--- a/mm/process_vm_access.c
+++ b/mm/process_vm_access.c
@@ -201,8 +201,8 @@ static ssize_t process_vm_rw_core(pid_t pid, struct iov_iter *iter,
 	}
 
 	mm = mm_access(task, PTRACE_MODE_ATTACH_REALCREDS);
-	if (!mm || IS_ERR(mm)) {
-		rc = IS_ERR(mm) ? PTR_ERR(mm) : -ESRCH;
+	if (IS_ERR(mm)) {
+		rc = PTR_ERR(mm);
 		/*
 		 * Explicitly map EACCES to EPERM as EPERM is a more
 		 * appropriate error code for process_vw_readv/writev

Re: Linux 6.12.99

[Dominique Martinet]

Greg Kroah-Hartman wrote on Wed, Jul 29, 2026 at 06:17:30PM +0200:
> Lorenzo Stoakes (1):
>       mm: refactor mm_access() to not return NULL

FWIW if anyone else cares and looks for this, this backport was required
due to a NULL deref in 6.12.98 (and likely .97 as well if commit
4bfe8c481846 ("proc: protect ptrace_may_access() with exec_update_lock
(part 1)") is indeed the culprit, I didn't check):
https://lore.kernel.org/all/2026072933-widow-grouped-f9e4@gregkh/T/#u


Greg & Sasha,
this is purely selfish and I'm grateful for all the work you two do
backporting patches, but (for next times) it'd be great if the backport
commit could also point at why it is backported after all this time
(for example add a comment or even just the above link between the
original sign-off and your's) -- it doesn't have to be much, but it took
me a while to find (I was curious because this was an urgent release
without -rc, with a single 2 year old patch branded as refactor not
fixing anything obvious...)

Ultimately it doesn't change the fact that "all users must upgrade" as
said in the announce, but I need to judge the urgency of the upgrade, so
having a rationale is extremely useful.
If backported commits fix something obvious then there's nothing to add,
but in this case I believe I'm not the only one who'd puzzle over it (if
someone is actually looking...)

Thanks!
-- 
Dominique Martinet

Re: Linux 6.12.99

[David Niklas]

On Mon, 10 Aug 2026 12:50:46 +0900
Dominique Martinet <asmadeus@codewreck.org> wrote:

> Greg Kroah-Hartman wrote on Wed, Jul 29, 2026 at 06:17:30PM +0200:
> > Lorenzo Stoakes (1):
> >       mm: refactor mm_access() to not return NULL  
> 
> FWIW if anyone else cares and looks for this, this backport was required
> due to a NULL deref in 6.12.98 (and likely .97 as well if commit
> 4bfe8c481846 ("proc: protect ptrace_may_access() with exec_update_lock
> (part 1)") is indeed the culprit, I didn't check):
> https://lore.kernel.org/all/2026072933-widow-grouped-f9e4@gregkh/T/#u
> 
> 
> Greg & Sasha,
> this is purely selfish and I'm grateful for all the work you two do
> backporting patches, but (for next times) it'd be great if the backport
> commit could also point at why it is backported after all this time
> (for example add a comment or even just the above link between the
> original sign-off and your's) -- it doesn't have to be much, but it took
> me a while to find (I was curious because this was an urgent release
> without -rc, with a single 2 year old patch branded as refactor not
> fixing anything obvious...)
> 
> Ultimately it doesn't change the fact that "all users must upgrade" as
> said in the announce, but I need to judge the urgency of the upgrade, so
> having a rationale is extremely useful.
> If backported commits fix something obvious then there's nothing to add,
> but in this case I believe I'm not the only one who'd puzzle over it (if
> someone is actually looking...)
> 
> Thanks!

Thanks for pointing that out, Dominique. I'll second the motion.