Depending on what part of the interrupt handling routine is being active the userspace of the process that was interrupted might not be accessible.
Generally supported CPUs have Advanced Programmable Interrupt Controllers (APIC) which can queue (or drop) interrupts in whatever order the OS sees it fit. Once an hardware interrupt has occured (or was forwarded by the APIC), it's interrupt handler will try to obtain a copy of any relevant data associated with that interrupt and push it on a work-queue (which resides in kernel address space) for some software interrupt handlers to handle later. After having pushed the data onto the work-queue, the hardware interrupt handler resumes execution of the interrupted proccess (in some events, it calls the scheduler instead).
A software interrupt handler might cause a scheduler run (or cause a hardware interrupt) instead of returning to the interrupted process.
Memory Mappings are process bound and the softint handler is AFAIK considered a proccess from the process and memory management point of view, therefore it can only access it's local kernel resources on top of the current process ones. A Pentium 3/4/D/M as well as any Core-i or Xeon (including Pentium Pro) and most of the AMD chips released in the last decade can address more than 4GB RAM while in 32 mode using physical address extensions (PAE). Nevertheless a single proccess running in 32-bit mode can never address more than 4 GB of memory at any time due to the address registers being limited. To address a different memory region (or range composition) the kernel's memory manager needs to reprogramm the MMU, which invalidates all previously active virtual<->physical mappings.
EDIT:
A process can never invalidate kernel resources unless the kernel allows this to the process. Nor can a process compromize or corrupt memory of other processes. In both cases, when a memory access is made, the CPU's integrated Translation Lookup Buffer (TLB) which only has limited size is checked. If the accessed memory page is "known" to the TLB, the address is permuted by it's TLB entry and the permutated value is used to handle the physical access. If the page is not in the TLB, the Memory Management Unit (MMU) issues a hardware interrupt called page fault, which causes the same-called kernel-routine to lookup the physical page corresponding to the virtual address of any segments allocated by the process. If a segment containing the virtual mapping is found, the corresponding entry is setup into the TLB (eventually after having been loaded from the file system or swap space) with some flags like Read-Only (e.g. to page-fault on write access and do a Copy-on-Write operation) or Not-Executable (for Data, mostly a security thing) and return to the process where the memory access is re-requested. If no segment containing the virtual mapping is found, the handler returns to the issuing proccess, just that it returns to the signal handler for the Segmentation Fault event, which about always ends up with "Segmentation Fault." being written onto stderr and the proccess aborting
By using this technique the kernel can granulate memory access on page (256 Bytes-Sequence in 32-bit mode) level, allow "load-on-demand" of any programm code, shared memory and context sharing (with and without copy-on-write) by assigning the same physical page to two or more processes or memory locking (by assigning the corresponding pages as inaccessible for any other proccess), efficient swapping (since the kernel keeps track of which pages are asked for at what regularity and swaps those least asked for) and of cause allocate-on-demand (malloc of 2GB data takes just a few cycles since the real allocation is done only when you actually access the memory).
