Linux 18.104.22.168 changes
Stefan Bader wrote:
> A short summary of the changes to stable and my thoughts on them. How
> will things proceed from there?
> - 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:
Note that the kernel gets its own page because it is special:
Tim Gardner email@example.com
kernel-team mailing list