[patch 0/9] 2.6.25.10 -stable review - Kernel

This is a discussion on [patch 0/9] 2.6.25.10 -stable review - Kernel ; This is the start of the stable review cycle for the 2.6.25.10 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: [patch 0/9] 2.6.25.10 -stable review

  1. [patch 0/9] 2.6.25.10 -stable review

    This is the start of the stable review cycle for the 2.6.25.10 release.
    There are 9 patches in this series, all will be posted as a response
    to this one. If anyone has any issues with these being applied, please
    let us know. If anyone is a maintainer of the proper subsystem, and
    wants to add a Signed-off-by: line to the patch, please respond with it.

    These patches are sent out with a number of different people on the
    Cc: line. If you wish to be a reviewer, please email stable@kernel.org
    to add your name to the list. If you want to be off the reviewer list,
    also email us.

    Responses should be made by July 3, 15:00:00 UTC. Anything received
    after that time might be too late.

    The whole patch series can be found in one patch at:
    kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.10-rc1.gz
    and the diffstat can be found below.


    thanks,

    the -stable release team


    Makefile | 2
    arch/x86/kernel/i387.c | 4 -
    arch/x86/kernel/ptrace.c | 45 +++++++------
    arch/x86/kernel/smpboot_64.c | 1
    drivers/char/drm/i915_drv.c | 1
    drivers/infiniband/hw/mthca/mthca_memfree.c | 6 +
    drivers/net/hamradio/6pack.c | 2
    drivers/net/hamradio/mkiss.c | 8 +-
    drivers/net/irda/irtty-sir.c | 4 -
    drivers/net/ppp_async.c | 3
    drivers/net/ppp_synctty.c | 3
    drivers/net/slip.c | 14 +++-
    drivers/net/wan/x25_asy.c | 10 ++-
    drivers/net/wireless/strip.c | 3
    include/asm-x86/msr.h | 2
    kernel/futex.c | 93 +++++++++++++++++++++-------
    kernel/sched.c | 1
    17 files changed, 147 insertions(+), 55 deletions(-)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. [patch 1/9] TTY: fix for tty operations bugs

    2.6.25-stable review patch. If anyone has any objections, please let us know.

    ------------------

    From: Alan Cox

    This is fixed with the recent tty operations rewrite in mainline in a
    different way, this is a selective backport of the relevant portions to
    the -stable tree.

    Signed-off-by: Alan Cox
    Signed-off-by: Greg Kroah-Hartman

    ---
    drivers/net/hamradio/6pack.c | 2 ++
    drivers/net/hamradio/mkiss.c | 8 ++++++--
    drivers/net/irda/irtty-sir.c | 4 +++-
    drivers/net/ppp_async.c | 3 +++
    drivers/net/ppp_synctty.c | 3 +++
    drivers/net/slip.c | 14 ++++++++++----
    drivers/net/wan/x25_asy.c | 10 ++++++++--
    drivers/net/wireless/strip.c | 3 ++-
    8 files changed, 37 insertions(+), 10 deletions(-)

    --- a/drivers/net/hamradio/6pack.c
    +++ b/drivers/net/hamradio/6pack.c
    @@ -601,6 +601,8 @@ static int sixpack_open(struct tty_struc

    if (!capable(CAP_NET_ADMIN))
    return -EPERM;
    + if (!tty->driver->write)
    + return -EOPNOTSUPP;

    dev = alloc_netdev(sizeof(struct sixpack), "sp%d", sp_setup);
    if (!dev) {
    --- a/drivers/net/hamradio/mkiss.c
    +++ b/drivers/net/hamradio/mkiss.c
    @@ -529,6 +529,7 @@ static void ax_encaps(struct net_device
    static int ax_xmit(struct sk_buff *skb, struct net_device *dev)
    {
    struct mkiss *ax = netdev_priv(dev);
    + int cib = 0;

    if (!netif_running(dev)) {
    printk(KERN_ERR "mkiss: %s: xmit call when iface is down\n", dev->name);
    @@ -544,10 +545,11 @@ static int ax_xmit(struct sk_buff *skb,
    /* 20 sec timeout not reached */
    return 1;
    }
    + if (ax->tty->drivers->chars_in_buffer)
    + cib = ax->tty->chars_in_buffer(ax->tty);

    printk(KERN_ERR "mkiss: %s: transmit timed out, %s?\n", dev->name,
    - (ax->tty->driver->chars_in_buffer(ax->tty) || ax->xleft) ?
    - "bad line quality" : "driver error");
    + cib || ax->xleft) ? "bad line quality" : "driver error");

    ax->xleft = 0;
    clear_bit(TTY_DO_WRITE_WAKEUP, &ax->tty->flags);
    @@ -736,6 +738,8 @@ static int mkiss_open(struct tty_struct

    if (!capable(CAP_NET_ADMIN))
    return -EPERM;
    + if (!tty->driver->write)
    + return -EOPNOTSUPP;

    dev = alloc_netdev(sizeof(struct mkiss), "ax%d", ax_setup);
    if (!dev) {
    --- a/drivers/net/irda/irtty-sir.c
    +++ b/drivers/net/irda/irtty-sir.c
    @@ -64,7 +64,9 @@ static int irtty_chars_in_buffer(struct
    IRDA_ASSERT(priv != NULL, return -1;
    IRDA_ASSERT(priv->magic == IRTTY_MAGIC, return -1;

    - return priv->tty->driver->chars_in_buffer(priv->tty);
    + if (priv->tty->drivers->chars_in_buffer)
    + return priv->tty->driver->chars_in_buffer(priv->tty);
    + return 0;
    }

    /* Wait (sleep) until underlaying hardware finished transmission
    --- a/drivers/net/ppp_async.c
    +++ b/drivers/net/ppp_async.c
    @@ -157,6 +157,9 @@ ppp_asynctty_open(struct tty_struct *tty
    {
    struct asyncppp *ap;
    int err;
    +
    + if (!tty->driver->write)
    + return -EOPNOTSUPP;

    err = -ENOMEM;
    ap = kzalloc(sizeof(*ap), GFP_KERNEL);
    --- a/drivers/net/ppp_synctty.c
    +++ b/drivers/net/ppp_synctty.c
    @@ -207,6 +207,9 @@ ppp_sync_open(struct tty_struct *tty)
    struct syncppp *ap;
    int err;

    + if (!tty->driver->write)
    + return -EOPNOTSUPP;
    +
    ap = kzalloc(sizeof(*ap), GFP_KERNEL);
    err = -ENOMEM;
    if (!ap)
    --- a/drivers/net/slip.c
    +++ b/drivers/net/slip.c
    @@ -460,10 +460,14 @@ static void sl_tx_timeout(struct net_dev
    /* 20 sec timeout not reached */
    goto out;
    }
    - printk(KERN_WARNING "%s: transmit timed out, %s?\n",
    - dev->name,
    - (sl->tty->driver->chars_in_buffer(sl->tty) || sl->xleft) ?
    - "bad line quality" : "driver error");
    + {
    + int cib = 0;
    + if (sl->tty->driver->chars_in_buffer)
    + cib = sl->tty->driver->chars_in_buffer(sl->tty);
    + printk(KERN_WARNING "%s: transmit timed out, %s?\n",
    + dev->name, (cib || sl->xleft) ?
    + "bad line quality" : "driver error");
    + }
    sl->xleft = 0;
    sl->tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP);
    sl_unlock(sl);
    @@ -829,6 +833,8 @@ static int slip_open(struct tty_struct *

    if (!capable(CAP_NET_ADMIN))
    return -EPERM;
    + if (!tty->driver->write)
    + return -EOPNOTSUPP;

    /* RTnetlink lock is misused here to serialize concurrent
    opens of slip channels. There are better ways, but it is
    --- a/drivers/net/wan/x25_asy.c
    +++ b/drivers/net/wan/x25_asy.c
    @@ -283,6 +283,10 @@ static void x25_asy_write_wakeup(struct
    static void x25_asy_timeout(struct net_device *dev)
    {
    struct x25_asy *sl = (struct x25_asy*)(dev->priv);
    + int cib = 0;
    +
    + if (sl->tty->driver->chars_in_buffer)
    + cib = sl->tty->driver->chars_in_buffer(sl->tty);

    spin_lock(&sl->lock);
    if (netif_queue_stopped(dev)) {
    @@ -290,8 +294,7 @@ static void x25_asy_timeout(struct net_d
    * 14 Oct 1994 Dmitry Gorodchanin.
    */
    printk(KERN_WARNING "%s: transmit timed out, %s?\n", dev->name,
    - (sl->tty->driver->chars_in_buffer(sl->tty) || sl->xleft) ?
    - "bad line quality" : "driver error");
    + (cib || sl->xleft) ? "bad line quality" : "driver error");
    sl->xleft = 0;
    sl->tty->flags &= ~(1 << TTY_DO_WRITE_WAKEUP);
    x25_asy_unlock(sl);
    @@ -561,6 +564,9 @@ static int x25_asy_open_tty(struct tty_s
    return -EEXIST;
    }

    + if (!tty->driver->write)
    + return -EOPNOTSUPP;
    +
    /* OK. Find a free X.25 channel to use. */
    if ((sl = x25_asy_alloc()) == NULL) {
    return -ENFILE;
    --- a/drivers/net/wireless/strip.c
    +++ b/drivers/net/wireless/strip.c
    @@ -802,7 +802,8 @@ static void set_baud(struct tty_struct *
    struct ktermios old_termios = *(tty->termios);
    tty->termios->c_cflag &= ~CBAUD; /* Clear the old baud setting */
    tty->termios->c_cflag |= baudcode; /* Set the new baud setting */
    - tty->driver->set_termios(tty, &old_termios);
    + if (tty->driver->set_termios)
    + tty->driver->set_termios(tty, &old_termios);
    }

    /*

    --
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. [patch 5/9] x86_64 ptrace: fix sys32_ptrace task_struct leak

    2.6.25-stable review patch. If anyone has any objections, please let us
    know.

    ------------------

    From: Roland McGrath

    Commit 5a4646a4efed8c835f76c3b88f3155f6ab5b8d9b introduced a leak of
    task_struct refs into sys32_ptrace. This bug has already gone away in
    for 2.6.26 in commit 562b80bafffaf42a6d916b0a2ee3d684220a1c10.

    Signed-off-by: Roland McGrath
    Acked-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    ---
    arch/x86/kernel/ptrace.c | 45 ++++++++++++++++++++++++++-------------------
    1 file changed, 26 insertions(+), 19 deletions(-)

    --- a/arch/x86/kernel/ptrace.c
    +++ b/arch/x86/kernel/ptrace.c
    @@ -1309,42 +1309,49 @@ asmlinkage long sys32_ptrace(long reques
    break;

    case PTRACE_GETREGS: /* Get all gp regs from the child. */
    - return copy_regset_to_user(child, &user_x86_32_view,
    - REGSET_GENERAL,
    - 0, sizeof(struct user_regs_struct32),
    - datap);
    + ret = copy_regset_to_user(child, &user_x86_32_view,
    + REGSET_GENERAL,
    + 0, sizeof(struct user_regs_struct32),
    + datap);
    + break;

    case PTRACE_SETREGS: /* Set all gp regs in the child. */
    - return copy_regset_from_user(child, &user_x86_32_view,
    - REGSET_GENERAL, 0,
    - sizeof(struct user_regs_struct32),
    - datap);
    + ret = copy_regset_from_user(child, &user_x86_32_view,
    + REGSET_GENERAL, 0,
    + sizeof(struct user_regs_struct32),
    + datap);
    + break;

    case PTRACE_GETFPREGS: /* Get the child FPU state. */
    - return copy_regset_to_user(child, &user_x86_32_view,
    - REGSET_FP, 0,
    - sizeof(struct user_i387_ia32_struct),
    - datap);
    + ret = copy_regset_to_user(child, &user_x86_32_view,
    + REGSET_FP, 0,
    + sizeof(struct user_i387_ia32_struct),
    + datap);
    + break;

    case PTRACE_SETFPREGS: /* Set the child FPU state. */
    - return copy_regset_from_user(
    + ret = copy_regset_from_user(
    child, &user_x86_32_view, REGSET_FP,
    0, sizeof(struct user_i387_ia32_struct), datap);
    + break;

    case PTRACE_GETFPXREGS: /* Get the child extended FPU state. */
    - return copy_regset_to_user(child, &user_x86_32_view,
    - REGSET_XFP, 0,
    - sizeof(struct user32_fxsr_struct),
    - datap);
    + ret = copy_regset_to_user(child, &user_x86_32_view,
    + REGSET_XFP, 0,
    + sizeof(struct user32_fxsr_struct),
    + datap);
    + break;

    case PTRACE_SETFPXREGS: /* Set the child extended FPU state. */
    - return copy_regset_from_user(child, &user_x86_32_view,
    + ret = copy_regset_from_user(child, &user_x86_32_view,
    REGSET_XFP, 0,
    sizeof(struct user32_fxsr_struct),
    datap);
    + break;

    default:
    - return compat_ptrace_request(child, request, addr, data);
    + ret = compat_ptrace_request(child, request, addr, data);
    + break;
    }

    out:

    --
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [patch 1/9] TTY: fix for tty operations bugs

    On Tue, Jul 01, 2008 at 08:18:59AM -0700, Greg KH wrote:
    > 2.6.25-stable review patch. If anyone has any objections, please let us know.
    >
    > ------------------
    >
    > From: Alan Cox
    >
    > This is fixed with the recent tty operations rewrite in mainline in a
    > different way, this is a selective backport of the relevant portions to
    > the -stable tree.
    >
    > Signed-off-by: Alan Cox
    > Signed-off-by: Greg Kroah-Hartman
    >
    > ---
    > drivers/net/hamradio/6pack.c | 2 ++
    > drivers/net/hamradio/mkiss.c | 8 ++++++--
    > drivers/net/irda/irtty-sir.c | 4 +++-


    Hm, there are a few build errors with this patch in these two files,
    I'll go respin it and do a new -rc release...

    Sorry for missing this before.

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [patch 0/9] 2.6.25.10 -stable review

    On Tue, Jul 01, 2008 at 08:18:35AM -0700, Greg KH wrote:
    > This is the start of the stable review cycle for the 2.6.25.10 release.
    > There are 9 patches in this series, all will be posted as a response
    > to this one. If anyone has any issues with these being applied, please
    > let us know. If anyone is a maintainer of the proper subsystem, and
    > wants to add a Signed-off-by: line to the patch, please respond with it.
    >
    > These patches are sent out with a number of different people on the
    > Cc: line. If you wish to be a reviewer, please email stable@kernel.org
    > to add your name to the list. If you want to be off the reviewer list,
    > also email us.
    >
    > Responses should be made by July 3, 15:00:00 UTC. Anything received
    > after that time might be too late.
    >
    > The whole patch series can be found in one patch at:
    > kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.10-rc1.gz
    > and the diffstat can be found below.


    I have released 2.6.25.10-rc2 at:
    kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.10-rc2.gz
    due to a build error in the -rc1 patch.

    Sorry about that.

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [patch 1/9] TTY: fix for tty operations bugs

    Hi Greg;

    01 Tem 2008 Sal tarihinde, Greg KH şunları yazmıştı:
    > On Tue, Jul 01, 2008 at 08:18:59AM -0700, Greg KH wrote:
    > > 2.6.25-stable review patch. If anyone has any objections, please let us know.
    > >
    > > ------------------
    > >
    > > From: Alan Cox
    > >
    > > This is fixed with the recent tty operations rewrite in mainline in a
    > > different way, this is a selective backport of the relevant portions to
    > > the -stable tree.
    > >
    > > Signed-off-by: Alan Cox
    > > Signed-off-by: Greg Kroah-Hartman
    > >
    > > ---
    > > drivers/net/hamradio/6pack.c | 2 ++
    > > drivers/net/hamradio/mkiss.c | 8 ++++++--
    > > drivers/net/irda/irtty-sir.c | 4 +++-

    >
    > Hm, there are a few build errors with this patch in these two files,
    > I'll go respin it and do a new -rc release...
    >
    > Sorry for missing this before.


    I still have following build error

    [...]
    drivers/net/hamradio/mkiss.c: In function 'ax_xmit':
    drivers/net/hamradio/mkiss.c:548: error: 'struct tty_struct' has no member named 'drivers'
    drivers/net/hamradio/mkiss.c:549: error: 'struct tty_struct' has no member named 'chars_in_buffer'
    drivers/net/hamradio/mkiss.c:552: warning: format '%s' expects type 'char *', but argument 3 has type 'int'
    drivers/net/hamradio/mkiss.c:552: error: expected ';' before ')' token
    drivers/net/hamradio/mkiss.c:552: error: expected statement before ')' token

    *** 4 errors, 1 warnings
    [...]

    after your

    commit bdd6248729d1f4a75e4623bce4f9c7737753b712
    Author: Greg Kroah-Hartman
    Date: Tue Jul 1 09:44:04 2008 -0700

    fix build error in tty patch

    commit to stable-queue

    Cheers
    --
    S.Çağlar Onur
    http://cekirdek.pardus.org.tr/~caglar/

    Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [patch 1/9] TTY: fix for tty operations bugs


    > drivers/net/hamradio/mkiss.c: In function 'ax_xmit':
    > drivers/net/hamradio/mkiss.c:548: error: 'struct tty_struct' has no member named 'drivers'
    > drivers/net/hamradio/mkiss.c:549: error: 'struct tty_struct' has no member named 'chars_in_buffer'
    > drivers/net/hamradio/mkiss.c:552: warning: format '%s' expects type 'char *', but argument 3 has type 'int'
    > drivers/net/hamradio/mkiss.c:552: error: expected ';' before ')' token
    > drivers/net/hamradio/mkiss.c:552: error: expected statement before ')' token


    Eugene Teo posted the patch to fix that.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [patch 1/9] TTY: fix for tty operations bugs

    On Wed, Jul 02, 2008 at 12:57:44PM +0300, S.Çağlar Onur wrote:
    > Hi Greg;
    >
    > 01 Tem 2008 Sal tarihinde, Greg KH şunları yazmıştı:
    > > On Tue, Jul 01, 2008 at 08:18:59AM -0700, Greg KH wrote:
    > > > 2.6.25-stable review patch. If anyone has any objections, please let us know.
    > > >
    > > > ------------------
    > > >
    > > > From: Alan Cox
    > > >
    > > > This is fixed with the recent tty operations rewrite in mainline in a
    > > > different way, this is a selective backport of the relevant portions to
    > > > the -stable tree.
    > > >
    > > > Signed-off-by: Alan Cox
    > > > Signed-off-by: Greg Kroah-Hartman
    > > >
    > > > ---
    > > > drivers/net/hamradio/6pack.c | 2 ++
    > > > drivers/net/hamradio/mkiss.c | 8 ++++++--
    > > > drivers/net/irda/irtty-sir.c | 4 +++-

    > >
    > > Hm, there are a few build errors with this patch in these two files,
    > > I'll go respin it and do a new -rc release...
    > >
    > > Sorry for missing this before.

    >
    > I still have following build error
    >
    > [...]
    > drivers/net/hamradio/mkiss.c: In function 'ax_xmit':
    > drivers/net/hamradio/mkiss.c:548: error: 'struct tty_struct' has no member named 'drivers'
    > drivers/net/hamradio/mkiss.c:549: error: 'struct tty_struct' has no member named 'chars_in_buffer'
    > drivers/net/hamradio/mkiss.c:552: warning: format '%s' expects type 'char *', but argument 3 has type 'int'
    > drivers/net/hamradio/mkiss.c:552: error: expected ';' before ')' token
    > drivers/net/hamradio/mkiss.c:552: error: expected statement before ')' token
    >
    > *** 4 errors, 1 warnings
    > [...]
    >
    > after your
    >
    > commit bdd6248729d1f4a75e4623bce4f9c7737753b712
    > Author: Greg Kroah-Hartman
    > Date: Tue Jul 1 09:44:04 2008 -0700
    >
    > fix build error in tty patch
    >
    > commit to stable-queue


    Are you sure you redid your patch set, I see fixes for the error
    messages above in that patch I did. I also don't get the build problems
    myself anymore.

    confused,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [patch 1/9] TTY: fix for tty operations bugs

    Hi;

    02 Tem 2008 Çar tarihinde, Greg KH şunları yazmıştı:
    > Are you sure you redid your patch set, I see fixes for the error
    > messages above in that patch I did. I also don't get the build problems
    > myself anymore.


    I start to hate myself , as you said refreshing whole patchset with quilt solved the compiliation problem, i thought i did refresh but i didn't, and compiled kernel works fine. I really have to drink some coffee.

    > confused,


    Sorry for your time...

    > greg k-h


    Cheers
    --
    S.Çağlar Onur
    http://cekirdek.pardus.org.tr/~caglar/

    Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [stable] Linux 2.6.25.10 (resume)

    First of all sorry for copy many people who maybe are not in the initial
    discussion, but since I've not been copied I have no idea who are and who
    are not in that thread

    The point that many people are trying to make is that Linux has a policy
    defined in a document (Documentation/SecurityBugs) but are not following it.

    Don't really matter to us what the policy is, but it's really important to
    follow it (many people, who are security professionals need that, and many
    others, who are NOT security professionals also).

    We all know (both sides) that it's impossible to know everything related to
    every bug and it's security impact. But there is a lot of different
    situations well-known as a security problems (because the bug class is well
    know, because someone reported it with details to the devels, etc). Hide it
    is an option, disclouse it is another. Have a policy is what matters. Say
    something and do another thing is always bad to everybody involved.


    P.S: I'm talking by myself, not for the company that I work for.


    Rodrigo Rubira Branco (BSDaemon).

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [stable] Linux 2.6.25.10 (resume)

    On Wed, Jul 16, 2008 at 01:01:24AM -0300, Rodrigo Rubira Branco wrote:
    > First of all sorry for copy many people who maybe are not in the initial
    > discussion, but since I've not been copied I have no idea who are and who
    > are not in that thread
    >
    > The point that many people are trying to make is that Linux has a policy
    > defined in a document (Documentation/SecurityBugs) but are not following it.


    {sigh}

    Are you sure? What specific sentance(s) are you saying that we are not
    currently following. And if not, can you propose a patch to the file to
    properly reflect how you seem to think we currently are working?

    getting very annoyed at people saying I am somehow doing the job I do
    for free, on my own time, incorrectly,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [stable] Linux 2.6.25.10 (resume)

    Greg KH escreveu:
    > On Wed, Jul 16, 2008 at 01:01:24AM -0300, Rodrigo Rubira Branco wrote:
    >
    >> First of all sorry for copy many people who maybe are not in the initial
    >> discussion, but since I've not been copied I have no idea who are and who
    >> are not in that thread
    >>
    >> The point that many people are trying to make is that Linux has a policy
    >> defined in a document (Documentation/SecurityBugs) but are not following it.
    >>

    >
    > {sigh}
    >
    > Are you sure? What specific sentance(s) are you saying that we are not
    > currently following. And if not, can you propose a patch to the file to
    > properly reflect how you seem to think we currently are working?
    >
    >

    Attached Please, let me know what do you think.

    > getting very annoyed at people saying I am somehow doing the job I do
    > for free, on my own time, incorrectly,
    >
    > greg k-h
    >

    For free? Hum, let's forget that you work as a linux developer... we are
    also trying to contribute in some way for free...


    P.S: It's obvious that my opinions are mine, not of my employer




    --- SecurityBugs.orig 2008-07-16 23:46:09.000000000 -0300
    +++ SecurityBugs 2008-07-17 14:58:32.000000000 -0300
    @@ -1,7 +1,7 @@
    -Linux kernel developers take security very seriously. As such, we'd
    -like to know when a security bug is found so that it can be fixed and
    -disclosed as quickly as possible. Please report security bugs to the
    -Linux kernel security team.
    +Linux kernel developers take security very seriously, in exactly the
    +same way we do with any other bugs. As such, we'd like to know when
    +a security bug is found so that it can be fixed as soon as possible.
    +Please report security bugs to the Linux kernel security team.

    1) Contact

    @@ -14,23 +14,24 @@
    As it is with any bug, the more information provided the easier it
    will be to diagnose and fix. Please review the procedure outlined in
    REPORTING-BUGS if you are unclear about what information is helpful.
    -Any exploit code is very helpful and will not be released without
    -consent from the reporter unless it has already been made public.
    +Any exploit code is very helpful and will not be released.

    2) Disclosure

    The goal of the Linux kernel security team is to work with the
    bug submitter to bug resolution as well as disclosure. We prefer
    -to fully disclose the bug as soon as possible. It is reasonable to
    +to not disclose the bug, since we believe any kind of bug deserves the
    +same attention and will be quickly patched. It is reasonable to
    delay disclosure when the bug or the fix is not yet fully understood,
    the solution is not well-tested or for vendor coordination. However, we
    expect these delays to be short, measurable in days, not weeks or months.
    A disclosure date is negotiated by the security team working with the
    -bug submitter as well as vendors. However, the kernel security team
    -holds the final say when setting a disclosure date. The timeframe for
    -disclosure is from immediate (esp. if it's already publically known)
    -to a few weeks. As a basic default policy, we expect report date to
    -disclosure date to be on the order of 7 days.
    +bug submitter as well as vendors if the submitter wants to disclose.
    +However, the kernel security team holds the final say when setting a
    +disclosure date. The timeframe for disclousure is from immediate (esp. if
    +it's already publically known) to a few weeks. As a basic default policy,
    +we expect report date to disclosure (if the submitter requires disclosure)
    +to be on the order of 7 days.

    3) Non-disclosure agreements




  13. Re: [stable] Linux 2.6.25.10 (resume)

    On Fri, Jul 18, 2008 at 11:07:45AM -0300, Rodrigo Rubira Branco (BSDaemon) wrote:
    > >getting very annoyed at people saying I am somehow doing the job I do
    > >for free, on my own time, incorrectly,
    > >
    > >greg k-h
    > >

    > For free? Hum, let's forget that you work as a linux developer... we are
    > also trying to contribute in some way for free...


    Rodrigo, this type of personal comment is unjustified and very inappropriate
    IMHO. It's not fair at all to judge people's personal involvement based on
    whom they work for. If you'd work at nights and week-ends after your job to
    backport bugfixes, you'd know what I'm talking about. BTW, one day you may
    notice that the most personally involved ones *finally* get a job at a Linux
    vendor's, and not the reverse.

    So please take care of not dismissing what people do on their own time, and
    try be kind enough to bring problems to them directly if any.

    Thanks,
    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [stable] Linux 2.6.25.10 (resume)

    Willy Tarreau escreveu:
    > On Fri, Jul 18, 2008 at 11:07:45AM -0300, Rodrigo Rubira Branco (BSDaemon) wrote:
    >
    >>> getting very annoyed at people saying I am somehow doing the job I do
    >>> for free, on my own time, incorrectly,
    >>>
    >>> greg k-h
    >>>
    >>>

    >> For free? Hum, let's forget that you work as a linux developer... we are
    >> also trying to contribute in some way for free...
    >>

    >
    > Rodrigo, this type of personal comment is unjustified and very inappropriate
    > IMHO. It's not fair at all to judge people's personal involvement based on
    > whom they work for. If you'd work at nights and week-ends after your job to
    > backport bugfixes, you'd know what I'm talking about. BTW, one day you may
    > notice that the most personally involved ones *finally* get a job at a Linux
    > vendor's, and not the reverse.
    >
    > So please take care of not dismissing what people do on their own time, and
    > try be kind enough to bring problems to them directly if any.
    >
    > Thanks,
    > Willy
    >
    >


    Hey Willy,

    Sorry, but my comment was not unjustified, since he started saying he is
    doing a free-job and we are saying is doing it 'wrong'.... That's not
    the case. We all are doing a free job, contributing in some way, not
    just you, him or me... Everybody involved in this discussion.

    But he, more than others, are also paid to do that job... Also, as a
    developer of any project so important as linux, doing that for free or
    not, you have a responsibility.
    You can choose to take it or not (I think that's why there is not many
    people with balls to accept it, and I congrats Greg for that).

    Just to finish my statement, let's stop this 'forks' on the main thread,
    please. I'm not here to judge anybody. Since it's an open project, we
    are trying to give our contribution as security researchers and as
    people who understand the security marketing.


    P.S.: Blahblahblah, disclaimer that this is my opinion and not the
    opinion of the company that I work for.


    Regards,


    Rodrigo (BSDaemon).
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [stable] Linux 2.6.25.10 (resume)

    On Fri, 18 Jul 2008, Rodrigo Rubira Branco (BSDaemon) wrote:

    > Willy Tarreau escreveu:
    >> On Fri, Jul 18, 2008 at 11:07:45AM -0300, Rodrigo Rubira Branco (BSDaemon)
    >> wrote:
    >>
    >>>> getting very annoyed at people saying I am somehow doing the job I do
    >>>> for free, on my own time, incorrectly,
    >>>>
    >>>> greg k-h
    >>>>
    >>> For free? Hum, let's forget that you work as a linux developer... we are
    >>> also trying to contribute in some way for free...
    >>>

    >>
    >> Rodrigo, this type of personal comment is unjustified and very
    >> inappropriate
    >> IMHO. It's not fair at all to judge people's personal involvement based on
    >> whom they work for. If you'd work at nights and week-ends after your job to
    >> backport bugfixes, you'd know what I'm talking about. BTW, one day you may
    >> notice that the most personally involved ones *finally* get a job at a
    >> Linux
    >> vendor's, and not the reverse.
    >>
    >> So please take care of not dismissing what people do on their own time, and
    >> try be kind enough to bring problems to them directly if any.
    >>
    >> Thanks,
    >> Willy
    >>
    >>

    >
    > Hey Willy,
    >
    > Sorry, but my comment was not unjustified, since he started saying he is
    > doing a free-job and we are saying is doing it 'wrong'.... That's not the
    > case. We all are doing a free job, contributing in some way, not just you,
    > him or me... Everybody involved in this discussion.
    > But he, more than others, are also paid to do that job...


    he's paied to work on what his company chooses to have him do for Linux.
    Greg is saying that he is doing all the -stable work on his own time,
    after finishing the work on Linux that his employer chooses to pay him
    for.

    > Also, as a
    > developer of any project so important as linux, doing that for free or not,
    > you have a responsibility.
    > You can choose to take it or not (I think that's why there is not many
    > people with balls to accept it, and I congrats Greg for that).


    if you would define the job up front and ask for someone to take it on you
    could then argue that they aren't doing it right. but when someone
    volunteers to do something and creates the job, claiming that they re
    doing it 'wrong' after the fact is insulting. the job is what he defined
    it to be when he created it. if you want to define the job differently you
    are welcome to do just that and start doing the different job (or hire
    someone to do the job). if you are right then Greg's work will be
    irrelavent and he can stop wasting his time. but unless you are willing to
    step up you should not take the tone that you have taken. you can ask for
    changes, explain why you think they are better, try and convince others,
    but you cannot say that he must or that he has a responsibility to do it
    your way.

    David Lang

    > Just to finish my statement, let's stop this 'forks' on the main thread,
    > please. I'm not here to judge anybody. Since it's an open project, we are
    > trying to give our contribution as security researchers and as people who
    > understand the security marketing.
    >
    >
    > P.S.: Blahblahblah, disclaimer that this is my opinion and not the opinion
    > of the company that I work for.
    >
    >
    > Regards,
    >
    >
    > Rodrigo (BSDaemon).
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    >

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [stable] Linux 2.6.25.10 (resume)

    > @@ -1,7 +1,7 @@
    > -Linux kernel developers take security very seriously. As such, we'd
    > -like to know when a security bug is found so that it can be fixed and
    > -disclosed as quickly as possible. Please report security bugs to the
    > -Linux kernel security team.
    > +Linux kernel developers take security very seriously, in exactly the
    > +same way we do with any other bugs. As such, we'd like to know when
    > +a security bug is found so that it can be fixed as soon as possible.
    > +Please report security bugs to the Linux kernel security team.


    NAK this. If the fix is not clear and the bug not too serious it is better
    to disclose it than fail to fix it. The security team does not usually fix the
    bugs, the experts in the various bits of code do.

    > -Any exploit code is very helpful and will not be released without
    > -consent from the reporter unless it has already been made public.
    > +Any exploit code is very helpful and will not be released.


    NAK this too. If someone releases an exploit publically or it leaks we
    want to be able to freely share it too. Your proposal would mean any but
    those dumb enough to agree to this could share it. That is why the unless made
    public is part of every generic NDA document on the planet.


    The rest needs Linus to return from holiday for discussion and that'll
    be a week or two. In the meantime you might want to define "disclose" as
    I don't think we all agree on what it means as you've not defined who is and
    isn't the linux security team and/or its helpers.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [stable] Linux 2.6.25.10 (resume)

    On Fri, Jul 18, 2008 at 11:07:45AM -0300, Rodrigo Rubira Branco (BSDaemon) wrote:
    > --- SecurityBugs.orig 2008-07-16 23:46:09.000000000 -0300
    > +++ SecurityBugs 2008-07-17 14:58:32.000000000 -0300
    > @@ -1,7 +1,7 @@
    > -Linux kernel developers take security very seriously. As such, we'd
    > -like to know when a security bug is found so that it can be fixed and
    > -disclosed as quickly as possible. Please report security bugs to the
    > -Linux kernel security team.
    > +Linux kernel developers take security very seriously, in exactly the
    > +same way we do with any other bugs. As such, we'd like to know when
    > +a security bug is found so that it can be fixed as soon as possible.
    > +Please report security bugs to the Linux kernel security team.


    I guess what is getting everyone's panties all in a bind is the term
    "disclosed", right? Why not just drop this word from the sentence
    instead of rewording it so much?

    > @@ -14,23 +14,24 @@
    > As it is with any bug, the more information provided the easier it
    > will be to diagnose and fix. Please review the procedure outlined in
    > REPORTING-BUGS if you are unclear about what information is helpful.
    > -Any exploit code is very helpful and will not be released without
    > -consent from the reporter unless it has already been made public.
    > +Any exploit code is very helpful and will not be released.


    I don't see why this needs to be changed, sometimes we do release
    exploit code to third parties that ask us nicely and the reporter allows
    us to.

    > 2) Disclosure
    >
    > The goal of the Linux kernel security team is to work with the
    > bug submitter to bug resolution as well as disclosure. We prefer
    > -to fully disclose the bug as soon as possible.


    Ah, again, it's the "fully disclose" that is causing panties to ride
    high. And again, we are disclosing the bug with the real fix and the
    code in question. We just seem to differ on what people consider
    "fully" it seems. I think the people liking that term these days
    consider that you must release exploit and other detailed information.

    I disagree with this and feel that our current policy of fixing bugs and
    releasing full code is pretty much the same thing as we are doing today,
    although I can understand the confusion. How about this rewording of
    the sentance instead:

    We prefer to fix and provide an update for the bug as soon as
    possible.

    So a simple 1 line change should be enough to stem this kind of argument
    in the future, right?

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [stable] Linux 2.6.25.10 (resume)

    On Sat, Jul 19, 2008 at 03:13:43PM -0700, Greg KH wrote:

    > I disagree with this and feel that our current policy of fixing bugs and
    > releasing full code is pretty much the same thing as we are doing today,
    > although I can understand the confusion. How about this rewording of
    > the sentance instead:
    >
    > We prefer to fix and provide an update for the bug as soon as
    > possible.
    >
    > So a simple 1 line change should be enough to stem this kind of argument
    > in the future, right?


    Not quite... OK, here's a story that might serve as a model
    of all that crap - it certainly runs afoul of a bunch of arguments on
    all sides of that.

    We all know that POSIX locks suck by design, in particular where it
    deals with close(2) semantics. "$FOO is associated with process P having
    a descriptor refering to opened file F, $FOO disappears when any of such
    descriptors get removed" is bloody inconvenient in a lot of respects. It
    also turns out to invite very similar kind of wrong assumptions in all
    implementation that have to deal with descriptor tables being possibly
    shared. So far the victims include:
    * FreeBSD POSIX locks; used to be vulnerable, fixed.
    * OpenBSD POSIX locks; vulnerable.
    * Linux POSIX locks and dnotify entries; used to be vulnerable, fixed.
    Plan9 happily avoids having these turds in the first place and IIRC NetBSD
    simply doesn't have means for sharing descriptor tables. Should such means
    appear it would be vulnerable as well. Dnotify is Linux-only, er, entity
    (as in "non sunt multiplicandam"). I haven't looked at Solaris and I couldn't
    care less about GNU Turd.

    In all cases vulnerablities are local, with impact ranging from
    user-triggered panic to rather unpleasant privelege escalations (e.g.
    "any user can send an arbitrary signal to arbitrary process" in case of
    dnotify, etc.)

    The nature of mistaken assumption is exactly the same in all cases.
    An object is associated with vnode/dentry/inode/whatnot and since it's
    destroyed on any close(), it is assumed that we shall be guaranteed that
    such objects will not be able to outlive the opened file they are associated
    with or the process creating them. It leads to the following nastiness:
    A and B share descriptor table.
    A: fcntl(fd, ...) trying to create such object; it resolves descriptor to
    opened file, pins it down for the duration of operation and blocks
    somewhere in course of creating the object.
    B: close(fd) evicts opened file from descriptor table. It finds no objects
    to be destroyed.
    A: completes creation of object, associates it with filesystem object and
    releases the temporary hold it had on opened file.

    At that point we have an obvious leak and slightly less obvious attack vector.
    If no other descriptors in the descriptor table of A and B used to refer to
    the same file, the object will not be destroyed since there will be nothing
    that could decide to destroy it. Unfortunately, it's worse than just a leak.
    These objects are supposed to be destroyed before the end of life of opened
    file. As the result, nobody bothers to have them affect refcounts on the
    file/vnode/dentry/inode/whatever. That's perfectly fine - the proper fix is
    to have fcntl() verify that descriptor still resolves to the same file before
    completing its work and destroy the object if it doesn't. You don't need to
    play with refcounts for that. However, without that fix we have a leak that
    leads to more than just an undead object - it's an undead object containing
    references to filesystem object that might be reused and to task_struct/proc/
    whatever you call it, again with the possibility of reuse.

    Getting from that point to the attack is a matter of simple (really simple)
    RTFS. Details obviously depend on what the kernel in question is doing to
    these objects, but with that kind of broken assertions it's really not hard
    to come up with exploitable holes.

    Now, let us look at the history:
    * POSIX locks support predates shared descriptor tables; the holes
    in question opened as soon as clone(2)/rfork(2) had been merged into a kernel
    and grown support for shared descriptor tables. For Linux it's 1.3.22 (Sep
    1995), for OpenBSD it's a bit before 2.0 (Jan 1996) for FreeBSD - 2.2 (Feb
    1996, from OpenBSD).
    * In 2002 dnotify had grown the same semantics (Linux-only thing,
    2.5.15, soon backported to 2.4.19). Same kind of race.
    * In 2003 FreeBSD folks had found and fixed their instance of that bug;
    commit message:
    "Avoid file lock leakage when linuxthreads port or rfork is used:
    - Mark the process leader as having an advisory lock
    - Check if process leader is marked as having advisory lock when
    closing file
    - Check that file is still open after lock has been obtained
    - Don't allow file descriptor table sharing between processes
    with different leaders"
    "Check that file is still open" bit refers to that race. I have no idea
    whether they'd realized that what they'd closed had been locally exploitable
    or not.
    * In 2005 Peter Staubach had noticed the Linux analog of that sucker.
    The fix had been along the same lines as FreeBSD one, but in case of Linux
    we had extra fun with SMP ordering. Peter had missed that and his patch
    left a hard to hit remnant of the race. His commit message is rather long;
    it starts with
    [PATCH] stale POSIX lock handling

    I believe that there is a problem with the handling of POSIX locks, which
    the attached patch should address.

    The problem appears to be a race between fcntl(2) and close(2). A
    multithreaded application could close a file descriptor at the same time as
    it is trying to acquire a lock using the same file descriptor. I would
    suggest that that multithreaded application is not providing the proper
    synchronization for itself, but the OS should still behave correctly.
    ....
    I'm 100% sure that in this case the vulnerability had _not_ been realized.
    Bogus behaviour had been noticed and (mostly) fixed, but implications had
    been missed, along with the fact that the same scenario had played out in
    dnotify.
    * This April I'd caught dnotify hole during code audit. The fix
    had been trivial enough and seeing that impact had been fairly nasty (any
    user could send any signal to any process, among other things) I'd decided
    to play along with "proper mechanisms". Meaning vendor-sec. _Bad_ error
    in judgement; the damn thing had not improved since I'd unsubscribed from
    that abortion. A trivial patch, obviously local to one function and obviously
    not modifying behaviour other than in case when existing tree would've screwed
    itself. Not affecting any headers. Not affecting any data structures.
    _Obviously_ not affecting any 3rd-party code - not even on binary level.
    IOW, as safe as it ever gets.
    Alas. The usual ****e had played out and we had a *MONTH-LONG*
    embargo. I would like to use this opportunity to offer a whole-hearted
    "**** you" to that lovely practice and to vendor-sec in general.
    * Very soon after writing the first version of a fix I started
    wondering if POSIX locks had the same hole - the same kind of semantics
    had invited the same kind of race there (eviction of dnotify entries and
    eviction of POSIX locks are called in the same place in close(2)). Current
    tree appeared to be OK, checking the history had shown Peter's patch.
    A bit after that I'd noticed insufficient locking in dnotify patch, fixed
    that. Checking for similar problems in POSIX locks counterpart of that crap
    had found the SMP ordering bug that remained there.
    * 2.6 -> 2.4 backport had uncovered another interesting thing -
    Peter's patch did _not_ make it to 2.4 3 years ago.
    * Checking OpenBSD (only now - I didn't get around to that back in
    April) shows that the same hole is alive and well there.

    Note that
    * OpenBSD folks hadn't picked the fix from FreeBSD ones, even though
    the FreeBSD version had been derived from OpenBSD one. Why? At a guess, the
    commit message had been less than noticable. Feel free to toss yourself off
    screaming "coverup" if you are so inclined; I don't swing that way...
    * Initial Linux fix _definitely_ had missed security implications
    *and* realization that somebody else might suffer from the same problem.
    FVO "somebody" including Linux itself, not to mention *BSD.
    * Even when the problem had been realized for what it had been in
    Linux, *BSD potential issues hadn't registered. Again, the same wunch
    of bankers is welcome to scream "coverup", but in this case we even have
    the bleeding CVEs.
    * CVEs or no CVEs, OpenBSD folks hadn't picked that one.
    * Going to vendor-sec is a mistake I won't repeat any time soon and
    I would strongly recommend everybody else to stay the hell away from that
    morass. It creates inexcusable delays, bounds you to confidentiality and,
    let's face it, happens to be the prime infiltration target for zero-day
    exploit traders. In _this_ case exploit had been local-only. Anything more
    interesting...

    So where does that leave us? Bugger if I know... FWIW, I would rather see
    implications thought about *and* mentioned in the changelogs. OTOH, the
    above shows the real-world cases when breakage hadn't even been realized to
    be security-significant. Obviously broken behaviour (leak, for example)
    gets spotted and fixed. Fix looks obviously sane, bug it deals with -
    obviously real and worth fixing, so into a tree it goes... IOW, one _can't_
    rely on having patches that close security holes marked as such. For that
    the authors have to notice that themselves in the first place. OTTH, nothing
    is going to convince the target audience of grsec, er, gentlemen that we are
    not a massive conspiracy anyway, the tinfoil brigade being what it is...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [stable] Linux 2.6.25.10 (resume)

    Alan Cox escreveu:
    >> @@ -1,7 +1,7 @@
    >> -Linux kernel developers take security very seriously. As such, we'd
    >> -like to know when a security bug is found so that it can be fixed and
    >> -disclosed as quickly as possible. Please report security bugs to the
    >> -Linux kernel security team.
    >> +Linux kernel developers take security very seriously, in exactly the
    >> +same way we do with any other bugs. As such, we'd like to know when
    >> +a security bug is found so that it can be fixed as soon as possible.
    >> +Please report security bugs to the Linux kernel security team.
    >>

    >
    > NAK this. If the fix is not clear and the bug not too serious it is better
    > to disclose it than fail to fix it. The security team does not usually fix the
    > bugs, the experts in the various bits of code do.
    >

    ACK Changed the sentence. Tks.

    >> -Any exploit code is very helpful and will not be released without
    >> -consent from the reporter unless it has already been made public.
    >> +Any exploit code is very helpful and will not be released.
    >>

    >
    > NAK this too. If someone releases an exploit publically or it leaks we
    > want to be able to freely share it too. Your proposal would mean any but
    > those dumb enough to agree to this could share it. That is why the unless made
    > public is part of every generic NDA document on the planet.
    >

    Agreed. Changed the sentence. Tks.
    > The rest needs Linus to return from holiday for discussion and that'll
    > be a week or two. In the meantime you might want to define "disclose" as
    > I don't think we all agree on what it means as you've not defined who is and
    > isn't the linux security team and/or its helpers.

    Cool.

    --- SecurityBugs.orig 2008-07-16 23:46:09.000000000 -0300
    +++ SecurityBugs 2008-07-21 07:28:01.000000000 -0300
    @@ -1,7 +1,9 @@
    -Linux kernel developers take security very seriously. As such, we'd
    -like to know when a security bug is found so that it can be fixed and
    -disclosed as quickly as possible. Please report security bugs to the
    -Linux kernel security team.
    +Linux kernel developers take security very seriously, in exactly the
    +same way we do with any other bugs. As such, we'd like to know when
    +a security bug is found so that it can be fixed as soon as possible by
    +the experts in this portion of the kernel code.
    +
    +Please report security bugs to the Linux kernel security team.

    1) Contact

    @@ -14,23 +16,26 @@
    As it is with any bug, the more information provided the easier it
    will be to diagnose and fix. Please review the procedure outlined in
    REPORTING-BUGS if you are unclear about what information is helpful.
    -Any exploit code is very helpful and will not be released without
    -consent from the reporter unless it has already been made public.
    +Any exploit code is very helpful and will not be released by our team
    +unless already made public. The exploit code may be shared with third
    +parties to facilitate a fix or to verify the vulnerability.

    2) Disclosure

    The goal of the Linux kernel security team is to work with the
    bug submitter to bug resolution as well as disclosure. We prefer
    -to fully disclose the bug as soon as possible. It is reasonable to
    +to not disclose the bug, since we believe any kind of bug deserves the
    +same attention and will be quickly patched. It is reasonable to
    delay disclosure when the bug or the fix is not yet fully understood,
    the solution is not well-tested or for vendor coordination. However, we
    expect these delays to be short, measurable in days, not weeks or months.
    A disclosure date is negotiated by the security team working with the
    -bug submitter as well as vendors. However, the kernel security team
    -holds the final say when setting a disclosure date. The timeframe for
    -disclosure is from immediate (esp. if it's already publically known)
    -to a few weeks. As a basic default policy, we expect report date to
    -disclosure date to be on the order of 7 days.
    +bug submitter as well as vendors if the submitter wants to disclose.
    +However, the kernel security team holds the final say when setting a
    +disclosure date. The timeframe for disclousure is from immediate (esp. if
    +it's already publically known) to a few weeks. As a basic default policy,
    +we expect report date to disclosure (if the submitter requires disclosure)
    +to be on the order of 7 days.

    3) Non-disclosure agreements



  20. Re: [stable] Linux 2.6.25.10 (resume)

    Greg KH escreveu:
    > On Fri, Jul 18, 2008 at 11:07:45AM -0300, Rodrigo Rubira Branco (BSDaemon) wrote:
    >
    >> --- SecurityBugs.orig 2008-07-16 23:46:09.000000000 -0300
    >> +++ SecurityBugs 2008-07-17 14:58:32.000000000 -0300
    >> @@ -1,7 +1,7 @@
    >> -Linux kernel developers take security very seriously. As such, we'd
    >> -like to know when a security bug is found so that it can be fixed and
    >> -disclosed as quickly as possible. Please report security bugs to the
    >> -Linux kernel security team.
    >> +Linux kernel developers take security very seriously, in exactly the
    >> +same way we do with any other bugs. As such, we'd like to know when
    >> +a security bug is found so that it can be fixed as soon as possible.
    >> +Please report security bugs to the Linux kernel security team.
    >>

    >
    > I guess what is getting everyone's panties all in a bind is the term
    > "disclosed", right? Why not just drop this word from the sentence
    > instead of rewording it so much?
    >

    No, it's not The problem is the policy of normal bugs = security
    bugs. If it's clear in the documentation, it will make people who need
    to backport patches aware of that and then they will need to care by
    themselves.

    The idea of start a project to keep track of that is not bad, but the
    problem is it's almost impossible to keep track of everything. The
    kernel developers knows about the bugs when they correct it, so just
    note as a security problem is not a big issue (but we already accepted
    it will not be done). Maybe if you guys accept to note it as a security
    issue at least to a group of people who can work on document it, it's
    cool to me
    >
    >> @@ -14,23 +14,24 @@
    >> As it is with any bug, the more information provided the easier it
    >> will be to diagnose and fix. Please review the procedure outlined in
    >> REPORTING-BUGS if you are unclear about what information is helpful.
    >> -Any exploit code is very helpful and will not be released without
    >> -consent from the reporter unless it has already been made public.
    >> +Any exploit code is very helpful and will not be released.
    >>

    >
    > I don't see why this needs to be changed, sometimes we do release
    > exploit code to third parties that ask us nicely and the reporter allows
    > us to.
    >

    Great, I agreed with that and already sent another version changing this
    sentence.

    >
    >> 2) Disclosure
    >>
    >> The goal of the Linux kernel security team is to work with the
    >> bug submitter to bug resolution as well as disclosure. We prefer
    >> -to fully disclose the bug as soon as possible.
    >>

    >
    > Ah, again, it's the "fully disclose" that is causing panties to ride
    > high. And again, we are disclosing the bug with the real fix and the
    > code in question. We just seem to differ on what people consider
    > "fully" it seems. I think the people liking that term these days
    > consider that you must release exploit and other detailed information.
    >
    >

    No, that's not true... We just want a sentence in the fix saying a
    security issue have been fixed. Not a detailed explanation, so the
    developers don't need to wast important time trying to understand
    security problems. The issue is that they know it's a security fix but
    they don't put that and sometimes they remove any reference to that
    > I disagree with this and feel that our current policy of fixing bugs and
    > releasing full code is pretty much the same thing as we are doing today,
    > although I can understand the confusion. How about this rewording of
    > the sentance instead:
    >
    > We prefer to fix and provide an update for the bug as soon as
    > possible.
    >
    > So a simple 1 line change should be enough to stem this kind of argument
    > in the future, right?
    >

    I really feel more confortable with the new version that I just sent -
    it's more cleaver about how it's handled... Please, give-me your
    insights on it too...


    cya,


    Rodrigo (BSDaemon).
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 2 1 2 LastLast