Kernel NULL pointer dereference leaves page 0 mapped

[Frank Lofaro]

There is a problem with how Linux handles a kernel null pointer dereference.
It sets pg0[0]=PAGE_SHARED (seems to be necessary to prevent the code that
displays what was executing at the time of the trap from trapping itself),
but it never sets it back via pg[0]=0.

Kernel null dereferences are not caught after the first one as a result,
and thus they show up as invalid operand, general protection, or g*d only
knows what.

2 possible solutions:

Keep pg0[0] = 0 and have kernel/traps.c check if the code it is going to
try to display is in an unmapped section of memory, etc (i.e verify_read
on the get_seg_byte).

_ or _

Set pg[0] = PAGE_SHARED on a null dereference, but set in back to 0 in
kernel/traps.c right before the do_exit(SIGSEGV).

[Linus Torvalds]

In article <1994Feb20.0...@unlv.edu>,

Frank Lofaro <ftlo...@unlv.edu> wrote:
>There is a problem with how Linux handles a kernel null pointer dereference.
>It sets pg0[0]=PAGE_SHARED (seems to be necessary to prevent the code that
>displays what was executing at the time of the trap from trapping itself),
>but it never sets it back via pg[0]=0.

Actually, this is a "feature": leaving the zero-page mapped after a NULL
pointer dereference means that we can try to return to the problematic
spot, and we *may* be able to shut down gracefully. Admittedly, this
means that we only catch the first NULL dereference that happens (and
there may be other problems after that due to the bug that resulted in
the NULL dereference in the first place)), but as they shouldn't happen
at all, that's enough (they can get fixed one at a time if they do
happen).

Linus