Kernel oops (unable to handle kernel paging request at virtual address) Three kinds of memory access exceptions

one, the Linux kernel, user space memory partition:

The following figure: Kernel space partition 0~3g for user space, 3~4g for kernel space. Please refer to "Linux User space and kernel space" in detail

Note: The scope of the kernel address space is 0xc0000000 ~ 0xFFFFFFFF

second, the oops caused by abnormal memory access:

1. Unable to handle kernel paging request in virtual Address 00000000

===== is more out of the kernel address space because of the use of NULL null pointers

2. Unable to handle kernel paging request in virtual address 20100110

===== is more out of the kernel address space because the memory is out of bounds, causing the pointer

The memory is corrupted. The next difficulty is where this memory has been modified. Why it was modified.

3, unable to handle kernel paging request at the virtual address c074838c

===== "No more out of the kernel address space, why also oops."

This is what I call it: trying to tamper with restricted memory. For example: A variable declared as const.

Are there other forms of restricted memory?

third, access to restricted memory results in oops:Const declares a variable to be read-only in C language, if you attempt to modify the const variable directly, the build stage compiler checks it out and reports read only errors, as follows: const int i = 1;
i = 10;
Build error:assignment of read-only variable ' i '//read-only variable assignment error

However, if the const variable is indirectly modified by the pointer, the compiler cannot check it out.
as follows: const int i = 1;
int *p = &i;
*p = 10;
As expected, the compilation succeeded. But don't be happy, such code is hidden. Because, obviously, we declare a variable to be const, in the hope that it will be protected. Since the compiler does not check for this vulnerability, who is responsible for protecting it? I think, Linux only run, by the MM module to protect the variable declared as const!!!??? But unfortunately, the Linux 3.4.5 Previous version has not been this protection function, should be the old version of Linux itself vulnerabilities. Until approximately Linux 3.4.67 (Android 4.4) has the ability to protect restricted memory at runtime.

It's easy to find out if you can indirectly modify a const variable directly using the pointer.

Here's a masking example:
static struct file_operations *new_file_operations = NULL;
static struct File_operations original_file_operations = {0};
ssize_t new_file_write (struct file *filp, const char __user *buf, size_t len, loff_t *ppos)
{
if (!iscanwrite (FILP))
{
RETURN-ENOSPC;
}

Return Original_file_operations.write (Filp, buf, Len, PPOs);
}

static int __init lowmemdetect_init (void)
{myfile = Filp_open ("/data", O_wronly | O_creat, 0);
if (!is_err (myfile) && (myfile->f_op!= NULL))
{
Original_file_operations.write = myfile->f_op->write; It point to Do_sync_write ()
Original_file_operations.aio_write = myfile->f_op->aio_write; It point to Ext4_file_write ()
New_file_operations = myfile->f_op; It point to ext4_file_operations//This cloak indirectly points the new_file_operations pointer to a const variable of kernel\fs\ext4\file.c Ext4_file_ Operations
New_file_operations->write = New_file_write; Modify Ext4_file_operations->write
This cloak indirectly modifies the const variable ext4_file_operations, which runs in the new version of Linux 3.4.67 (Android 4.4) causing oops.
Filp_close (MyFile, NULL);
}
}
/* Declare const variable: kernel\fs\ext4\file.c
const struct File_operations ext4_file_operations = {
. Llseek = Ext4_llseek,
. Read = Do_sync_read,
. write = Do_sync_write,
. Aio_read = Generic_file_aio_read,
. Aio_write = Ext4_file_write,
*/

The Linux 3.4.67 (Android 4.4) version kernel How to protect restricted memory. Further study is still needed.