2.6.24-stable review
Subsystems (9)
cover 2.6.24-stable review
This is the start of the stable review cycle for the 2.6.24-stable release. There are 12 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 [email protected] to add your name to the list. If you want to be off the reviewer list, also email us.
Responses should be made by Thursday, May 1 16: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.24.6-rc1.gz
and the diffstat can be found below.
thanks,
the -stable release team
------------------------
Makefile | 2 +- arch/x86/kernel/io_apic_32.c | 1 + drivers/isdn/capi/capidrv.c | 9 +++++---- drivers/isdn/i4l/isdn_net.c | 1 + drivers/media/video/cx88/cx88-cards.c | 4 ++++ drivers/media/video/ivtv/ivtv-ioctl.c | 3 ++- drivers/net/tehuti.c | 15 +++++++++++++++ drivers/usb/gadget/ether.c | 1 + drivers/usb/serial/usb-serial.c | 2 ++ fs/jffs2/erase.c | 18 ++++++++---------- fs/splice.c | 2 +- include/net/tcp.h | 7 +++++-- 12 files changed, 46 insertions(+), 19 deletions(-)
PATCH 1/12 splice: use mapping_gfp_mask
2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
upstream commit: 4cd13504652d28e16bf186c6bb2bbb3725369383
The loop block driver is careful to mask __GFP_IO|__GFP_FS out of its mapping_gfp_mask, to avoid hangs under memory pressure. But nowadays it uses splice, usually going through __generic_file_splice_read. That must use mapping_gfp_mask instead of GFP_KERNEL to avoid those hangs.
--- fs/splice.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/splice.c +1 -1
@@ -314,7 +314,7 @@ __generic_file_splice_read(struct file *break ; error =add_to_page_cache_lru (page, mapping, index, -GFP_KERNEL ); +mapping_gfp_mask (mapping));if (unlikely (error)) {page_cache_release (page);if (error == -EEXIST )
PATCH 2/12 fix oops on rmmod capidrv
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: Karsten Keil <[email protected]>
commit eb36f4fc019835cecf0788907f6cab774508087b upstream.
Fix overwriting the stack with the version string (it is currently 10 bytes + zero) when unloading the capidrv module. Safeguard against overwriting it should the version string grow in the future.
Should fix Kernel Bug Tracker Bug 9696.
--- drivers/isdn/capi/capidrv.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/isdn/capi/capidrv.c +5 -4
@@ -2332,13 +2332,14 @@ static int __init capidrv_init(void) static void __exit capidrv_exit(void) { -char rev[10 ]; +char rev[32 ];char *p;if ((p =strchr (revision,':' )) !=0 ) { -strcpy (rev, p +1 ); - p =strchr (rev,'$' ); - *p =0 ; +strncpy (rev, p +1 ,sizeof (rev)); + rev[sizeof (rev)-1 ] =0 ; +if ((p =strchr (rev,'$' )) !=0 ) + *p =0 ; }else {strcpy (rev," ??? " ); }
PATCH 3/12 x86: Fix 32-bit x86 MSI-X allocation leakage
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: PJ Waskiewicz <[email protected]>
commit 9d9ad4b51d2b29b5bbeb4011f5e76f7538119cf9 upstream
This bug was introduced in the 2.6.24 i386/x86_64 tree merge, where MSI-X vector allocation will eventually fail. The cause is the new bit array tracking used vectors is not getting cleared properly on IRQ destruction on the 32-bit APIC code.
This can be seen easily using the ixgbe 10 GbE driver on multi-core systems by simply loading and unloading the driver a few times. Depending on the number of available vectors on the host system, the MSI-X allocation will eventually fail, and the driver will only be able to use legacy interrupts.
--- arch/x86/kernel/io_apic_32.c | 1 + 1 file changed, 1 insertion(+)
arch/x86/kernel/io_apic_32.c +1 -0
@@ -2478,6 +2478,7 @@ void destroy_irq(unsigned int irq)dynamic_irq_cleanup (irq);spin_lock_irqsave (&vector_lock, flags); +clear_bit (irq_vector[irq], used_vectors); irq_vector[irq] =0 ;spin_unlock_irqrestore (&vector_lock, flags); }
PATCH 4/12 tehuti: check register size (CVE-2008-1675)
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: Francois Romieu <[email protected]>
--- drivers/net/tehuti.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/net/tehuti.c +14 -0
@@ -625,6 +625,12 @@ static void __init bdx_firmware_endianes s_firmLoad[i] =CPU_CHIP_SWAP32 (s_firmLoad[i]); } +static int bdx_range_check (struct bdx_priv *priv,u32 offset) +{ +return (offset > (u32) (BDX_REGS_SIZE / priv->nic->port_num)) ? + -EINVAL :0 ; +} +static int bdx_ioctl_priv (struct net_device *ndev,struct ifreq *ifr,int cmd) {struct bdx_priv *priv = ndev->priv;
@@ -646,6 +652,9 @@ static int bdx_ioctl_priv(struct net_devswitch (data[0 ]) {case BDX_OP_READ : + error =bdx_range_check (priv, data[1 ]); +if (error <0 ) +return error; data[2 ] =READ_REG (priv, data[1 ]);DBG ("read_reg(0x%x)=0x%x (dec %d)\n" , data[1 ], data[2 ], data[2 ]);
@@ -655,6 +664,11 @@ static int bdx_ioctl_priv(struct net_devbreak ;case BDX_OP_WRITE : +if (!capable (CAP_NET_ADMIN )) +return -EPERM ; + error =bdx_range_check (priv, data[1 ]); +if (error <0 ) +return error;WRITE_REG (priv, data[1 ], data[2 ]);DBG ("write_reg(0x%x, 0x%x)\n" , data[1 ], data[2 ]);break ;
PATCH 5/12 tehuti: move ioctl perm check closer to function start (CVE-2008-1675)
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jeff Garzik <[email protected]>
Commit f946dffed6334f08da065a89ed65026ebf8b33b4 upstream
Noticed by davem.
--- drivers/net/tehuti.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/tehuti.c +3 -2
@@ -649,6 +649,9 @@ static int bdx_ioctl_priv(struct net_devDBG ("%d 0x%x 0x%x\n" , data[0 ], data[1 ], data[2 ]); } +if (!capable (CAP_NET_ADMIN )) +return -EPERM ; +switch (data[0 ]) {case BDX_OP_READ :
@@ -664,8 +667,6 @@ static int bdx_ioctl_priv(struct net_devbreak ;case BDX_OP_WRITE : -if (!capable (CAP_NET_ADMIN )) -return -EPERM ; error =bdx_range_check (priv, data[1 ]);if (error <0 )return error;
PATCH 6/12 USB: gadget: queue usb USB_CDC_GET_ENCAPSULATED_RESPONSE message
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jan Altenberg <[email protected]>
backport of 41566bcf35a8b23ce4715dadb5acfd1098c1d3e4
commit 0cf4f2de0a0f4100795f38ef894d4910678c74f8 introduced a bug, which prevents sending an USB_CDC_GET_ENCAPSULATED_RESPONSE message. This breaks the RNDIS initialization (especially / only Windoze machines dislike this behavior...).
--- drivers/usb/gadget/ether.c | 1 + 1 file changed, 1 insertion(+)
drivers/usb/gadget/ether.c +1 -0
@@ -1561,6 +1561,7 @@ done_set_intf:memcpy (req->buf, buf, n); req->complete = rndis_response_complete;rndis_free_response (dev->rndis_config, buf); + value = n; }/* else stalls ... spec says to avoid that */ }
PATCH 7/12 JFFS2: Fix free space leak with in-band cleanmarkers
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: David Woodhouse <[email protected]>
We were accounting for the cleanmarker by calling jffs2_link_node_ref() (without locking!), which adjusted both superblock and per-eraseblock accounting, subtracting the size of the cleanmarker from {jeb,c}->free_size and adding it to {jeb,c}->used_size.
But only _then_ were we adding the size of the newly-erased block back to the superblock counts, and we were adding each of jeb->{free,used}_size to the corresponding superblock counts. Thus, the size of the cleanmarker was effectively subtracted from the superblock's free_size _twice_.
Fix this, by always adding a full eraseblock size to c->free_size when we've erased a block. And call jffs2_link_node_ref() under the proper lock, while we're at it.
Thanks to Alexander Yurchenko and/or Damir Shayhutdinov for (almost) pinpointing the problem.
[Backport of commit 014b164e1392a166fe96e003d2f0e7ad2e2a0bb7]
--- fs/jffs2/erase.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-)
fs/jffs2/erase.c +8 -10
@@ -419,9 +419,6 @@ static void jffs2_mark_erased_block(struif (jffs2_write_nand_cleanmarker (c, jeb)) goto filebad; } - -/* Everything else got zeroed before the erase */ - jeb->free_size = c->sector_size; }else {struct kvec vecs[1 ];
@@ -449,18 +446,19 @@ static void jffs2_mark_erased_block(stru goto filebad; } - -/* Everything else got zeroed before the erase */ - jeb->free_size = c->sector_size; -/* FIXME Special case for cleanmarker in empty block */ -jffs2_link_node_ref (c, jeb, jeb->offset |REF_NORMAL , c->cleanmarker_size,NULL ); } +/* Everything else got zeroed before the erase */ + jeb->free_size = c->sector_size;down (&c->erase_free_sem);spin_lock (&c->erase_completion_lock); + c->erasing_size -= c->sector_size; - c->free_size += jeb->free_size; - c->used_size += jeb->used_size; + c->free_size += c->sector_size; + +/* Account for cleanmarker now, if it's in-band */ +if (c->cleanmarker_size && !jffs2_cleanmarker_oob (c)) +jffs2_link_node_ref (c, jeb, jeb->offset |REF_NORMAL , c->cleanmarker_size,NULL );jffs2_dbg_acct_sanity_check_nolock (c,jeb);jffs2_dbg_acct_paranoia_check_nolock (c, jeb);
PATCH 9/12 USB: remove broken usb-serial num_endpoints check
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit: 07c3b1a1001614442c665570942a3107a722c314
The num_interrupt_in, num_bulk_in, and other checks in the usb-serial code are just wrong, there are too many different devices out there with different numbers of endpoints. We need to just be sticking with the device ids instead of trying to catch this kind of thing. It broke too many different devices.
This fixes a large number of usb-serial devices to get them working properly again.
--- drivers/usb/serial/usb-serial.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/usb-serial.c +2 -0
@@ -844,6 +844,7 @@ int usb_serial_probe(struct usb_interfac serial->num_interrupt_in = num_interrupt_in; serial->num_interrupt_out = num_interrupt_out; +#if 0 /* check that the device meets the driver's requirements */ if ((type->num_interrupt_in !=NUM_DONT_CARE && type->num_interrupt_in != num_interrupt_in)
@@ -857,6 +858,7 @@ int usb_serial_probe(struct usb_interfackfree (serial);return -EIO ; } +#endif /* found all that we need */ dev_info(&interface->dev, "%s converter detected\n",
PATCH 9/12 USB: remove broken usb-serial num_endpoints check
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit: 07c3b1a1001614442c665570942a3107a722c314
The num_interrupt_in, num_bulk_in, and other checks in the usb-serial code are just wrong, there are too many different devices out there with different numbers of endpoints. We need to just be sticking with the device ids instead of trying to catch this kind of thing. It broke too many different devices.
This fixes a large number of usb-serial devices to get them working properly again.
--- drivers/usb/serial/usb-serial.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/serial/usb-serial.c +2 -0
@@ -844,6 +844,7 @@ int usb_serial_probe(struct usb_interfac serial->num_interrupt_in = num_interrupt_in; serial->num_interrupt_out = num_interrupt_out; +#if 0 /* check that the device meets the driver's requirements */ if ((type->num_interrupt_in !=NUM_DONT_CARE && type->num_interrupt_in != num_interrupt_in)
@@ -857,6 +858,7 @@ int usb_serial_probe(struct usb_interfackfree (serial);return -EIO ; } +#endif /* found all that we need */ dev_info(&interface->dev, "%s converter detected\n",
PATCH 10/12 V4L: Fix VIDIOCGAP corruption in ivtv
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: Alan Cox <[email protected]>
Frank Bennett reported that ivtv was causing skype to crash. With help from one of their developers he showed it was a kernel problem. VIDIOCGCAP copies a name into a fixed length buffer - ivtv uses names that are too long and does not truncate them so corrupts a few bytes of the app data area.
Possibly the names also want trimming but for now this should fix the corruption case.
--- drivers/media/video/ivtv/ivtv-ioctl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/media/video/ivtv/ivtv-ioctl.c +2 -1
@@ -727,7 +727,8 @@ int ivtv_v4l2_ioctls(struct ivtv *itv, smemset (vcap,0 ,sizeof (*vcap));strcpy (vcap->driver,IVTV_DRIVER_NAME );/* driver name */ -strcpy (vcap->card, itv->card_name);/* card type */ +strncpy (vcap->card, itv->card_name, +sizeof (vcap->card)-1 );/* card type */ strcpy (vcap->bus_info,pci_name (itv->dev));/* bus info... */ vcap->version =IVTV_DRIVER_VERSION ;/* version */ vcap->capabilities = itv->v4l2_cap;/* capabilities */
PATCH 11/12 V4L: cx88: enable radio GPIO correctly
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
From: Steven Toth <[email protected]>
This patch fixes an issue on the HVR1300, where GPIO is blown away due to the radio input being undefined, breaking the functionality of the DVB demodulator and MPEG2 encoder used on the cx8802 mpeg TS port.
This is a minimal patch for 2.6.26 and the -stable series. This must be fixed a better way for 2.6.27.
--- drivers/media/video/cx88/cx88-cards.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/media/video/cx88/cx88-cards.c +4 -0
@@ -1349,6 +1349,10 @@ static const struct cx88_board cx88_boar }}, /* fixme: Add radio support */ .mpeg = CX88_MPEG_DVB | CX88_MPEG_BLACKBIRD, + .radio = { + .type = CX88_RADIO, + .gpio0 = 0xe780, + }, }, [CX88_BOARD_ADSTECH_PTV_390] = { .name = "ADS Tech Instant Video PCI",
PATCH 12/12 ISDN: Do not validate ISDN net device address prior to interface-up
In reply to Greg KH2.6.24-stable review patch. If anyone has any objections, please let us know.
------------------
Commit bada339 (Validate device addr prior to interface-up) caused a regression in the ISDN network code, see: http://bugzilla.kernel.org/show_bug.cgi?id=9923
The trivial fix is to remove the pointer to eth_validate_addr() in the net_device struct in isdn_net_init().
--- drivers/isdn/i4l/isdn_net.c | 1 + 1 file changed, 1 insertion(+)
drivers/isdn/i4l/isdn_net.c +1 -0
@@ -2010,6 +2010,7 @@ isdn_net_init(struct net_device *ndev) ndev->flags =IFF_NOARP |IFF_POINTOPOINT ; ndev->type =ARPHRD_ETHER ; ndev->addr_len =ETH_ALEN ; + ndev->validate_addr =NULL ;/* for clients with MPPP maybe higher values better */ ndev->tx_queue_len =30 ;
Quoted 3 lines · Jörg-Volker Peetz
How about this one?
looks good indeed, and needs to be fixed in 2.4 too. However it's still not in mailine, so the author needs to ping the stable team when this gets merged (or repost with stable on a CC line in the commit message, as Greg recently told me :-))
Willy
I demand that Jörg-Volker Peetz may or may not have written...
Quoted 2 lines
How about this one?
http://lkml.org/lkml/2008/4/7/55
And this one? http://lkml.org/lkml/2008/3/13/232
(commit 03c086a747d0b242878eb881971ec61c1555869d)
Signature · 5 lines
| Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT. <!-- Message headers are taken from the ussg lkml archive ;-) -->
Quoted 7 lines · Darren Salt
I demand that J??rg-Volker Peetz may or may not have written...
Quoted 2 lines
How about this one?
http://lkml.org/lkml/2008/4/7/55And this one? http://lkml.org/lkml/2008/3/13/232
(commit03c086a747d0b242878eb881971ec61c1555869d)
Did anyone send it to [email protected] and ask for it to be included?
thanks,
greg k-h
I demand that Greg KH may or may not have written...
Quoted 8 lines · Darren Salt
Quoted 5 lines
I demand that J??rg-Volker Peetz may or may not have written...
Quoted 2 lines
How about this one?
http://lkml.org/lkml/2008/4/7/55And this one? http://lkml.org/lkml/2008/3/13/232
(commit03c086a747d0b242878eb881971ec61c1555869d)Did anyone send it to [email protected] and ask for it to be included?
I sent it to stable@ when I originally submitted the patch. The message ID is <4F84E87BA4%[email protected]>.
Signature · 5 lines
| Darren Salt | linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | Let's keep the pound sterling You will triumph over your enemy.
Quoted 6 lines · Darren Salt
I demand that Greg KH may or may not have written...
Quoted 4 lines · Darren Salt
Quoted 3 lines
I demand that J??rg-Volker Peetz may or may not have written...
Quoted 2 lines
How about this one?
http://lkml.org/lkml/2008/4/7/55
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
And this one? http://lkml.org/lkml/2008/3/13/232
(commit03c086a747d0b242878eb881971ec61c1555869d)Did anyone send it to [email protected] and ask for it to be included?
I sent it to stable@ when I originally submitted the patch. The message ID is <4F84E87BA4%[email protected]>.
Ok, I see it now.
In it you did not mention if this change was already in Linus's tree, and if so, what git id it was. As you sent it primarily to lkml, I assumed that it was not upstream at this time, hence I did not apply it.
As 2.6.24 is pretty much not being maintained anymore, I don't think this is an issue anymore :)
thanks,
greg k-h