msr_open tests for someone trying to open a device for a nonexistent CPU.
However, the function always returns 0, not ret like it should, hence userspace
can BUG the kernel trivially. This bug was introduced by the cdev lock_kernel
pushdown patch last May.
The BUG can be reproduced with these commands:
# mknod fubar c 202 8 <-- pick a number less than NR_CPUS that is not
the number of an online CPU
# cat fubar
Signed-off-by: Darrick J. Wong <[email protected]>
---
arch/x86/kernel/msr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 9fd8095..e439380 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -131,7 +131,7 @@ static int msr_open(struct inode *inode, struct file *file)
ret = -EIO; /* MSR not supported */
out:
unlock_kernel();
- return 0;
+ return ret;
}
/*
* Darrick J. Wong <[email protected]> wrote:
> msr_open tests for someone trying to open a device for a nonexistent CPU.
> However, the function always returns 0, not ret like it should, hence userspace
> can BUG the kernel trivially. This bug was introduced by the cdev lock_kernel
> pushdown patch last May.
>
> The BUG can be reproduced with these commands:
>
> # mknod fubar c 202 8 <-- pick a number less than NR_CPUS that is not
> the number of an online CPU
> # cat fubar
applied to tip/x86/urgent - thanks Darrick.
Ingo
On Thu, 14 Aug 2008 15:43:33 -0700
"Darrick J. Wong" <[email protected]> wrote:
> msr_open tests for someone trying to open a device for a nonexistent
> CPU. However, the function always returns 0, not ret like it should,
> hence userspace can BUG the kernel trivially. This bug was
> introduced by the cdev lock_kernel pushdown patch last May.
> - return 0;
> + return ret;
Oops, that was pretty silly. Apologies for the screwup.
jon