[redhat-lspp] kernel oops (Re: lspp.7 kernel released)

[Russell Coker]

On Mon, 2006-02-13 at 13:55 -0600, Klaus Weidner wrote:
> I've tried the kernel, and get the following kernel oops when doing a
> "/bin/su -" on an ssh login in enforcing mode:
> 
> idr_remove called for id=1 which is not allocated.
>  [<c01c62fa>] sub_remove+0xbb/0xc3     [<c014333f>] cache_free_debugcheck+0x190/0x198
>  [<c020bdb5>] release_dev+0x63f/0x68b     [<c01c631a>] idr_remove+0x18/0x74
>  [<c020bdea>] release_dev+0x674/0x68b     [<c013f7da>] __alloc_pages+0x67/0x275
>  [<c011915e>] __wake_up+0x2a/0x3d     [<c020a3a9>] tty_ldisc_enable+0x1e/0x20
>  [<c020b4b6>] init_dev+0x352/0x452     [<c020c0a9>] tty_open+0x2a8/0x2cc
>  [<c015d858>] chrdev_open+0xe9/0x128     [<c015d76f>] chrdev_open+0x0/0x128
>  [<c01554e8>] __dentry_open+0xb7/0x186     [<c015565b>] nameidata_to_filp+0x19/0x28
>  [<c01555dd>] filp_open+0x26/0x2c     [<c0155763>] get_unused_fd+0xae/0xb6
>  [<c015582a>] do_sys_open+0x33/0x9e     [<c0102d15>] syscall_call+0x7/0xb
> 
> Let me know if this rings a bell, or if you want me to file a bug for
> this.

In the past we've seen idr_remove messages when permission to
access /dev/pts/whatever was granted but no search access to /dev/pts
was granted.  The kernel code issue in question was regarded as not
easily/usefully solvable so policy that grants access
to /dev/pts/whatever without granting the scontext in question access
to /dev/pts is considered a bug.