Bug #7477


secflags panic in shmem_lock

Added by Patrick Mooney almost 6 years ago. Updated almost 6 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:


When issuing an SHM_LOCk shmctl, there's a panic in the new secflags bits:

a.out: #pf Page fault
Bad kernel fault at addr=0x648
pid=4967, pc=0xfffffffffba794f0, sp=0xffffff0008241970, eflags=0x10282
cr0: 80050033<pg,wp,ne,et,mp,pe> cr4: 6f8<xmme,fxsr,pge,mce,pae,pse,de>
cr2: 648cr3: 10404d000cr8: c

        rdi:                0 rsi:                1 rdx:                0
        rcx: ffffff025559a810  r8: fffffd7fffe00000  r9:                0
        rax:                1 rbx:                0 rbp: ffffff0008241980
        r10:                0 r11:             1000 r12:             1000
        r13: ffffff0008241ba0 r14: ffffff0008241bdc r15: fffffffffba97570
        fsb: fffffd7fff172a40 gsb: ffffff024cf23040  ds:                0
         es:                0  fs:                0  gs:                0
        trp:                e err:                0 rip: fffffffffba794f0
         cs:               30 rfl:            10282 rsp: ffffff0008241970
         ss:               38

ffffff0008241760 unix:die+df ()
ffffff0008241870 unix:trap+e18 ()
ffffff0008241880 unix:_cmntrap+e6 ()
ffffff0008241980 genunix:secflag_enabled+10 ()
ffffff00082419d0 unix:valid_usr_range+79 ()
ffffff0008241a20 genunix:seg_alloc+f6 ()
ffffff0008241ad0 genunix:as_map_segvn_segs+28e ()
ffffff0008241b60 genunix:as_map_ansegs+b1 ()
ffffff0008241c40 genunix:as_map_locked+39a ()
ffffff0008241cb0 genunix:as_map+58 ()
ffffff0008241d40 shmsys:shmem_lock+bd ()
ffffff0008241ec0 shmsys:shmctl+482 ()
ffffff0008241f00 shmsys:shmsys+90 ()
ffffff0008241f10 unix:brand_sys_syscall+21d ()

Looking at the src to valid_usr_range, the issue becomes apparent:

valid_usr_range(caddr_t addr, size_t len, uint_t prot, struct as *as,
    caddr_t userlimit)
        caddr_t eaddr = addr + len;

        if (eaddr <= addr || addr >= userlimit || eaddr > userlimit)
                return (RANGE_BADADDR);

        if ((addr <= (caddr_t)forbidden_null_mapping_sz) &&
            secflag_enabled(as->a_proc, PROC_SEC_FORBIDNULLMAP))
                return (RANGE_BADADDR);

This as has no a_proc set. That seems unusual, but shmem_lock provides an explanation:
        as = as_alloc();
        /* Initialize the create arguments and map the segment */
        crargs = *(struct segvn_crargs *)zfod_argsp;    /* structure copy */
        crargs.offset = (u_offset_t)0;
        crargs.type = MAP_SHARED;
        crargs.amp = amp;
        crargs.prot = PROT_ALL;
        crargs.maxprot = crargs.prot;
        crargs.flags = 0;
        error = as_map(as, 0x0, amp->size, segvn_create, &crargs);

It's using an empty address space in order to do this memory locking. Looking around, it appears that seg_spt also makes use of non-associated AS allocations in this way. The easy short term fix would be to confirm a non-NULL a_proc before making the secflags check.

Here is an easy reproducer:

#include <unistd.h>
#include <sys/ipc.h>
#include <sys/shm.h>

int main()
        key_t key;
        int pid, shmid;

        pid = getpid();
        key = ftok("/var/tmp", pid);
        shmid = shmget(key, 4096, IPC_CREAT | IPC_EXCL);
        shmctl(shmid, SHM_LOCK, NULL);
        shmctl(shmid, IPC_RMID, NULL);

Related issues

Related to illumos gate - Feature #7478: shmat needs to honor the null mapping secflagNew2016-10-18

Actions #1

Updated by Patrick Mooney almost 6 years ago

Original SmartOS bug report:

Actions #2

Updated by Robert Mustacchi almost 6 years ago

  • Related to Feature #7478: shmat needs to honor the null mapping secflag added
Actions #3

Updated by Electric Monk almost 6 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit a02406b914e6386bb2bc0fff011f0b5add5d9152

commit  a02406b914e6386bb2bc0fff011f0b5add5d9152
Author: Patrick Mooney <>
Date:   2016-10-18T21:37:26.000Z

    7477 secflags panic in shmem_lock
    Reviewed by: Jerry Jelinek <>
    Reviewed by: Robert Mustacchi <>
    Reviewed by: Richard Lowe <>
    Approved by: Dan McDonald <>


Also available in: Atom PDF