FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 05-01-2008, 11:35 PM
Stefan Bader
 
Default Linux 2.6.24.6 changes

A short summary of the changes to stable and my thoughts on them. How
will things proceed from there?

Stefan


- Fix dnotify/close race (CVE-2008-1375)
should take
- ISDN: Do not validate ISDN net device address prior to interface up
probably not important
- V4L: cx88: enable radio GPIO correctly
should take (causes huge amounts of logging)
- V4L: Fix VIDIOCGAP corruption in ivtv
causes memory corruption, worth taking, though I don't know
oth a bug report
- USB: remove broken usb-serial num_endpoints check
not critical, though it claims to help to make several
serial drivers working.
- increase the max_burst threshold from 3 to tp->reordering (tcp)
Sound not critical
- JFFS2: Fix free space leak with in-band cleanmarkers.
Also doesn't sound highly critical to me.
- USB: gadget: queue usb USB_CDC_GET_ENCAPSULATED_RESPONSE message
not critical
- tehuti: move ioctl perm check closer to function start (CVE-2008-1675)
should take, thought never heard of tehuti
- tehuti: check register size (CVE-2008-1675)
should take
- x86: Fix 32-bit x86 MSI-X allocation leakage
though not fatal it sounds a bit desireable.
- fix oops on rmmod capidrv
oops should qualify but important enough?
- splice: use mapping_gfp_mask
should take, since hangs in loop sound nasty


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 05-02-2008, 01:42 PM
Tim Gardner
 
Default Linux 2.6.24.6 changes

Stefan Bader wrote:
> A short summary of the changes to stable and my thoughts on them. How
> will things proceed from there?
>
> Stefan
>
>
> - Fix dnotify/close race (CVE-2008-1375)
> should take
> - ISDN: Do not validate ISDN net device address prior to interface up
> probably not important
> - V4L: cx88: enable radio GPIO correctly
> should take (causes huge amounts of logging)
> - V4L: Fix VIDIOCGAP corruption in ivtv
> causes memory corruption, worth taking, though I don't know
> oth a bug report
> - USB: remove broken usb-serial num_endpoints check
> not critical, though it claims to help to make several
> serial drivers working.
> - increase the max_burst threshold from 3 to tp->reordering (tcp)
> Sound not critical
> - JFFS2: Fix free space leak with in-band cleanmarkers.
> Also doesn't sound highly critical to me.
> - USB: gadget: queue usb USB_CDC_GET_ENCAPSULATED_RESPONSE message
> not critical
> - tehuti: move ioctl perm check closer to function start (CVE-2008-1675)
> should take, thought never heard of tehuti
> - tehuti: check register size (CVE-2008-1675)
> should take
> - x86: Fix 32-bit x86 MSI-X allocation leakage
> though not fatal it sounds a bit desireable.
> - fix oops on rmmod capidrv
> oops should qualify but important enough?
> - splice: use mapping_gfp_mask
> should take, since hangs in loop sound nasty
>
>

I know this isn't what you asked, but let me lay a bit of SRU philosophy
on you. Some folks on the list may not yet have heard my diatribe.

CVE's are no brainers. As for the rest, each must demonstrably fix a
specific problem (and must have a Launchpad bug report). In this regard,
'specific problem' means kernel oops or some other severe denial of
service. Even that is no guarantee, especially if the issue only affects
one machine with some obscure piece of hardware. Issues for which there
exists a benign work around do _not_ qualify. Simple, uncontroversial
quirks _might_ qualify, but are typically only accepted if there are
other pressing SRU cases that trigger an upload.

In any case, I expect _all_ SRU patches to pass through this mailing
list. Each must accumulate at least 2 sign-off's from kernel core-devs,
one of whom must be on the Canonical kernel team. (yes - I noticed not
everything on the first Hardy SRU upload went by the book. We'll do
better next time).

Here is the general SRU policy page:

https://wiki.ubuntu.com/StableReleaseUpdates

Note that the kernel gets its own page because it is special:

https://wiki.ubuntu.com/KernelUpdates

rtg
--
Tim Gardner tim.gardner@ubuntu.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 07:17 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org