2007-02-21 01:50:56

by Greg KH

[permalink] [raw]
Subject: [patch 00/18] 2.6.18-stable review

This is the start of the stable review cycle for the 2.6.18.8 release.

This will be the last release of the 2.6.18-stable series, so if there
are patches that you feel should be applied to that tree, please let me
know.

There are 18 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 Friday February 23 00:00 UTC. Anything
received after that time might be too late.

The whole patch set can be downloaded at:
kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.18.8-rc1.gz

thanks,

the -stable release team


2007-02-21 01:51:04

by Greg KH

[permalink] [raw]
Subject: [patch 01/18] bcm43xx: Fix for oops on resume

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

------------------
From: Larry Finger <[email protected]>

There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop.

Signed-off-by: Larry Finger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/bcm43xx/bcm43xx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -21,7 +21,7 @@
#define PFX KBUILD_MODNAME ": "

#define BCM43xx_SWITCH_CORE_MAX_RETRIES 50
-#define BCM43xx_IRQWAIT_MAX_RETRIES 50
+#define BCM43xx_IRQWAIT_MAX_RETRIES 100

#define BCM43xx_IO_SIZE 8192


--

2007-02-21 01:51:21

by Greg KH

[permalink] [raw]
Subject: [patch 03/18] Dont leak NT bit into next task

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

------------------
From: Andi Kleen <[email protected]>

SYSENTER can cause a NT to be set which might cause crashes on the IRET
in the next task.

Following similar i386 patch from Linus.

Signed-off-by: Andi Kleen <[email protected]>
[backport from Chuck Ebbert]
Signed-off-by: Chuck Ebbert <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86_64/kernel/entry.S | 4 ++++
arch/x86_64/kernel/setup64.c | 4 ++++
include/asm-x86_64/system.h | 5 +++--
3 files changed, 11 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/arch/x86_64/kernel/entry.S
+++ linux-2.6.18.7/arch/x86_64/kernel/entry.S
@@ -146,6 +146,10 @@
/* rdi: prev */
ENTRY(ret_from_fork)
CFI_DEFAULT_STACK
+ push kernel_eflags(%rip)
+ CFI_ADJUST_CFA_OFFSET 4
+ popf # reset kernel eflags
+ CFI_ADJUST_CFA_OFFSET -4
call schedule_tail
GET_THREAD_INFO(%rcx)
testl $(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT),threadinfo_flags(%rcx)
--- linux-2.6.18.7.orig/arch/x86_64/kernel/setup64.c
+++ linux-2.6.18.7/arch/x86_64/kernel/setup64.c
@@ -178,6 +178,8 @@ void __cpuinit check_efer(void)
}
}

+unsigned long kernel_eflags;
+
/*
* cpu_init() initializes state that is per-CPU. Some data is already
* initialized (naturally) in the bootstrap process, such as the GDT
@@ -290,4 +292,6 @@ void __cpuinit cpu_init (void)
set_debugreg(0UL, 7);

fpu_init();
+
+ raw_local_save_flags(kernel_eflags);
}
--- linux-2.6.18.7.orig/include/asm-x86_64/system.h
+++ linux-2.6.18.7/include/asm-x86_64/system.h
@@ -14,12 +14,13 @@
#define __RESTORE(reg,offset) "movq (14-" #offset ")*8(%%rsp),%%" #reg "\n\t"

/* frame pointer must be last for get_wchan */
-#define SAVE_CONTEXT "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
-#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
+#define SAVE_CONTEXT "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
+#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"

#define __EXTRA_CLOBBER \
,"rcx","rbx","rdx","r8","r9","r10","r11","r12","r13","r14","r15"

+/* Save restore flags to clear handle leaking NT */
#define switch_to(prev,next,last) \
asm volatile(SAVE_CONTEXT \
"movq %%rsp,%P[threadrsp](%[prev])\n\t" /* save RSP */ \

--

2007-02-21 01:51:44

by Greg KH

[permalink] [raw]
Subject: [patch 02/18] bcm43xx: Fix for oops on ampdu status

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

------------------
From: Michael Buesch <[email protected]>

If bcm43xx were to process an afterburner (ampdu) status response, Linux would oops. The
ampdu and intermediate status bits are properly named.

Signed-off-by: Michael Buesch <[email protected]>
Signed-off-by: Larry Finger <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 8 +++-----
drivers/net/wireless/bcm43xx/bcm43xx_xmit.h | 10 ++--------
2 files changed, 5 insertions(+), 13 deletions(-)

--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1449,12 +1449,10 @@ static void handle_irq_transmit_status(s

bcm43xx_debugfs_log_txstat(bcm, &stat);

- if (stat.flags & BCM43xx_TXSTAT_FLAG_IGNORE)
+ if (stat.flags & BCM43xx_TXSTAT_FLAG_AMPDU)
+ continue;
+ if (stat.flags & BCM43xx_TXSTAT_FLAG_INTER)
continue;
- if (!(stat.flags & BCM43xx_TXSTAT_FLAG_ACK)) {
- //TODO: packet was not acked (was lost)
- }
- //TODO: There are more (unknown) flags to test. see bcm43xx_main.h

if (bcm43xx_using_pio(bcm))
bcm43xx_pio_handle_xmitstatus(bcm, &stat);
--- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
+++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx_xmit.h
@@ -137,14 +137,8 @@ struct bcm43xx_xmitstatus {
u16 unknown; //FIXME
};

-#define BCM43xx_TXSTAT_FLAG_ACK 0x01
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x02
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x04
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x08
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x10
-#define BCM43xx_TXSTAT_FLAG_IGNORE 0x20
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x40
-//TODO #define BCM43xx_TXSTAT_FLAG_??? 0x80
+#define BCM43xx_TXSTAT_FLAG_AMPDU 0x10
+#define BCM43xx_TXSTAT_FLAG_INTER 0x20

u8 bcm43xx_plcp_get_ratecode_cck(const u8 bitrate);
u8 bcm43xx_plcp_get_ratecode_ofdm(const u8 bitrate);

--

2007-02-21 01:51:56

by Greg KH

[permalink] [raw]
Subject: [patch 04/18] SCSI: add missing cdb clearing in scsi_execute()

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

------------------
From: Tejun Heo <[email protected]>

Clear-garbage-after-CDB patch missed scsi_execute() and it causes some
ODDs (HL-DT-ST DVD-RAM GSA-H30N) choke during SCSI scan. Note that
this patch is only for -stable. There is another more reliable fix
for this problem proposed for devel tree.

http://thread.gmane.org/gmane.linux.ide/14605/focus=14605

Signed-off-by: Tejun Heo <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Douglas Gilbert <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/scsi/scsi_lib.c | 1 +
1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/drivers/scsi/scsi_lib.c
+++ linux-2.6.18.7/drivers/scsi/scsi_lib.c
@@ -191,6 +191,7 @@ int scsi_execute(struct scsi_device *sde
goto out;

req->cmd_len = COMMAND_SIZE(cmd[0]);
+ memset(req->cmd, 0, BLK_MAX_CDB); /* ATAPI hates garbage after CDB */
memcpy(req->cmd, cmd, req->cmd_len);
req->sense = sense;
req->sense_len = 0;

--

2007-02-21 01:52:32

by Greg KH

[permalink] [raw]
Subject: [patch 13/18] V4L: cx88: Fix lockup on suspend

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

------------------
From: Robert Hancock <[email protected]>

Suspending with the cx88xx module loaded causes the system to lock up
because the cx88_audio_thread kthread was missing a try_to_freeze()
call, which caused it to go into a tight loop and result in softlockup
when suspending. Fix that.

(cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09)

Signed-off-by: Robert Hancock <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/video/cx88/cx88-tvaudio.c | 2 ++
1 file changed, 2 insertions(+)

--- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-tvaudio.c
+++ linux-2.6.18.7/drivers/media/video/cx88/cx88-tvaudio.c
@@ -38,6 +38,7 @@
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/errno.h>
+#include <linux/freezer.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/mm.h>
@@ -979,6 +980,7 @@ int cx88_audio_thread(void *data)
msleep_interruptible(1000);
if (kthread_should_stop())
break;
+ try_to_freeze();

/* just monitor the audio status for now ... */
memset(&t, 0, sizeof(t));

--

2007-02-21 01:52:36

by Greg KH

[permalink] [raw]
Subject: [patch 12/18] v4l: cx88: Fix leadtek_eeprom tagging

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

------------------
From: Jean Delvare <[email protected]>

reference to .init.text: from .text between 'cx88_card_setup'
(at offset 0x68c) and 'cx88_risc_field'
Caused by leadtek_eeprom() being declared __devinit and called from
a non-devinit context.

(cherry picked from commit 69f7e75a9d45e5eaca16917a8d0dedf76149f13f)

Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/video/cx88/cx88-cards.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-cards.c
+++ linux-2.6.18.7/drivers/media/video/cx88/cx88-cards.c
@@ -1465,7 +1465,7 @@ const unsigned int cx88_idcount = ARRAY_
/* ----------------------------------------------------------------------- */
/* some leadtek specific stuff */

-static void __devinit leadtek_eeprom(struct cx88_core *core, u8 *eeprom_data)
+static void leadtek_eeprom(struct cx88_core *core, u8 *eeprom_data)
{
/* This is just for the "Winfast 2000XP Expert" board ATM; I don't have data on
* any others.

--

2007-02-21 01:53:07

by Greg KH

[permalink] [raw]
Subject: [patch 14/18] V4L: Fix quickcam communicator driver for big endian architectures

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

------------------
From: Grant Likely <[email protected]>

Host endianess does not affect the order that pixel rgb data comes
in from the quickcam (the values are bytes, not words or longs). The
driver is erroniously swapping the order of rgb values for big endian
machines. This patch is needed get the Quickcam communicator working
on big endian machines (tested on powerpc)

(cherry picked from commit c6d704c8c4453f05717ba88792f70f8babf95268)

Signed-off-by: Grant Likely <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/video/usbvideo/quickcam_messenger.h | 14 --------------
1 file changed, 14 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/video/usbvideo/quickcam_messenger.h
+++ linux-2.6.18.7/drivers/media/video/usbvideo/quickcam_messenger.h
@@ -35,27 +35,13 @@ struct rgb {
};

struct bayL0 {
-#ifdef __BIG_ENDIAN
- u8 r;
- u8 g;
-#elif __LITTLE_ENDIAN
u8 g;
u8 r;
-#else
-#error not byte order defined
-#endif
};

struct bayL1 {
-#ifdef __BIG_ENDIAN
- u8 g;
- u8 b;
-#elif __LITTLE_ENDIAN
u8 b;
u8 g;
-#else
-#error not byte order defined
-#endif
};

struct cam_size {

--

2007-02-21 01:53:20

by Greg KH

[permalink] [raw]
Subject: [patch 16/18] V4L: tveeprom: autodetect LG TAPC G701D as tuner type 37

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

------------------
From: Michael Krufky <[email protected]>

Autodetect LG TAPC G701D as tuner type 37, fixing
mis-detected tuners in some Hauppauge tv tuner cards.

Thanks to Adonis Papas, for pointing this out.

(cherry picked from commit 1323fbda1343f50f198bc8bd6d1d59c8b7fc45bf)

Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/video/tveeprom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/media/video/tveeprom.c
+++ linux-2.6.18.7/drivers/media/video/tveeprom.c
@@ -184,7 +184,7 @@ hauppauge_tuner[] =
{ TUNER_ABSENT, "Thompson DTT757"},
/* 80-89 */
{ TUNER_ABSENT, "Philips FQ1216LME MK3"},
- { TUNER_ABSENT, "LG TAPC G701D"},
+ { TUNER_LG_PAL_NEW_TAPC, "LG TAPC G701D"},
{ TUNER_LG_NTSC_NEW_TAPC, "LG TAPC H791F"},
{ TUNER_LG_PAL_NEW_TAPC, "TCL 2002MB 3"},
{ TUNER_LG_PAL_NEW_TAPC, "TCL 2002MI 3"},

--

2007-02-21 01:53:08

by Greg KH

[permalink] [raw]
Subject: [patch 10/18] dvb-core: fix bug in CRC-32 checking on 64-bit systems

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

------------------
From: Ang Way Chuang <[email protected]>

CRC-32 checking during ULE decapsulation always failed on x86_64 systems due
to the size of a variable used to store CRC. This bug was discovered on
Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such
problem. This patch has been tested on 64-bit system as well as 32-bit system.

(cherry picked from commit dedcefb085fe98a1feaf63590fe2fc7e0ecb1987)

Signed-off-by: Ang Way Chuang <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/dvb/dvb-core/dvb_net.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/dvb/dvb-core/dvb_net.c
+++ linux-2.6.18.7/drivers/media/dvb/dvb-core/dvb_net.c
@@ -604,7 +604,7 @@ static void dvb_net_ule( struct net_devi
{ &utype, sizeof utype },
{ priv->ule_skb->data, priv->ule_skb->len - 4 }
};
- unsigned long ule_crc = ~0L, expected_crc;
+ u32 ule_crc = ~0L, expected_crc;
if (priv->ule_dbit) {
/* Set D-bit for CRC32 verification,
* if it was set originally. */
@@ -617,7 +617,7 @@ static void dvb_net_ule( struct net_devi
*((u8 *)priv->ule_skb->tail - 2) << 8 |
*((u8 *)priv->ule_skb->tail - 1);
if (ule_crc != expected_crc) {
- printk(KERN_WARNING "%lu: CRC32 check FAILED: %#lx / %#lx, SNDU len %d type %#x, ts_remain %d, next 2: %x.\n",
+ printk(KERN_WARNING "%lu: CRC32 check FAILED: %08x / %08x, SNDU len %d type %#x, ts_remain %d, next 2: %x.\n",
priv->ts_count, ule_crc, expected_crc, priv->ule_sndu_len, priv->ule_sndu_type, ts_remain, ts_remain > 2 ? *(unsigned short *)from_where : 0);

#ifdef ULE_DEBUG

--

2007-02-21 01:53:20

by Greg KH

[permalink] [raw]
Subject: [patch 17/18] V4L: buf_qbuf: fix videobuf_queue->stream corruption and lockup

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

------------------
From: Oleg Nesterov <[email protected]>

We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.

(cherry picked from commit 419dd8378dfa32985672ab7927b4bc827f33b332)

Signed-off-by: Oleg Nesterov <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/video/video-buf.c | 1 +
1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/drivers/media/video/video-buf.c
+++ linux-2.6.18.7/drivers/media/video/video-buf.c
@@ -695,6 +695,7 @@ videobuf_qbuf(struct videobuf_queue *q,
goto done;
}
if (buf->state == STATE_QUEUED ||
+ buf->state == STATE_PREPARED ||
buf->state == STATE_ACTIVE) {
dprintk(1,"qbuf: buffer is already queued or active.\n");
goto done;

--

2007-02-21 01:53:07

by Greg KH

[permalink] [raw]
Subject: [patch 09/18] IB/mad: Fix race between cancel and receive completion

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

------------------
From: Roland Dreier <[email protected]>

When ib_cancel_mad() is called, it puts the canceled send on a list
and schedules a "flushed" callback from process context. However,
this leaves a window where a receive completion could be processed
before the send is fully flushed.

This is fine, except that ib_find_send_mad() will find the MAD and
return it to the receive processing, which results in the sender
getting both a successful receive and a "flushed" send completion for
the same request. Understandably, this confuses the sender, which is
expecting only one of these two callbacks, and leads to grief such as
a use-after-free in IPoIB.

Fix this by changing ib_find_send_mad() to return a send struct only
if the status is still successful (and not "flushed"). The search of
the send_list already had this check, so this patch just adds the same
check to the search of the wait_list.

Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---

---
drivers/infiniband/core/mad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/infiniband/core/mad.c
+++ linux-2.6.18.7/drivers/infiniband/core/mad.c
@@ -1750,7 +1750,7 @@ ib_find_send_mad(struct ib_mad_agent_pri
*/
(is_direct(wc->recv_buf.mad->mad_hdr.mgmt_class) ||
rcv_has_same_gid(mad_agent_priv, wr, wc)))
- return wr;
+ return (wr->status == IB_WC_SUCCESS) ? wr : NULL;
}

/*

--

2007-02-21 01:51:56

by Greg KH

[permalink] [raw]
Subject: [patch 05/18] IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G

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

------------------
From: Roland Dreier <[email protected]>

struct srp_device.fmr_page_mask was unsigned long, which means that
the top part of addresses above 4G was being chopped off on 32-bit
architectures. Of course nothing good happens when data from SRP
targets is DMAed to the wrong place.

Fix this by changing fmr_page_mask to u64, to match the addresses
actually used by IB devices.

Thanks to Brian Cain <[email protected]> and David McMillen
<[email protected]> for help diagnosing the bug and testing
the fix.

Signed-off-by: Roland Dreier <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/ulp/srp/ib_srp.c | 2 +-
drivers/infiniband/ulp/srp/ib_srp.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/drivers/infiniband/ulp/srp/ib_srp.c
+++ linux-2.6.18.7/drivers/infiniband/ulp/srp/ib_srp.c
@@ -1851,7 +1851,7 @@ static void srp_add_one(struct ib_device
*/
srp_dev->fmr_page_shift = max(9, ffs(dev_attr->page_size_cap) - 1);
srp_dev->fmr_page_size = 1 << srp_dev->fmr_page_shift;
- srp_dev->fmr_page_mask = ~((unsigned long) srp_dev->fmr_page_size - 1);
+ srp_dev->fmr_page_mask = ~((u64) srp_dev->fmr_page_size - 1);

INIT_LIST_HEAD(&srp_dev->dev_list);

--- linux-2.6.18.7.orig/drivers/infiniband/ulp/srp/ib_srp.h
+++ linux-2.6.18.7/drivers/infiniband/ulp/srp/ib_srp.h
@@ -87,7 +87,7 @@ struct srp_device {
struct ib_fmr_pool *fmr_pool;
int fmr_page_shift;
int fmr_page_size;
- unsigned long fmr_page_mask;
+ u64 fmr_page_mask;
};

struct srp_host {

--

2007-02-21 01:52:36

by Greg KH

[permalink] [raw]
Subject: [patch 06/18] i2c: fix broken ds1337 initialization

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

------------------
From: Dirk Eibach <[email protected]>

On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to
2.6.18 broke RTC support.

The main problem are changes to ds1337_init_client().
When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7
in status register is set. This has to be reset by writing 0 to status
register. But since there are only 16 byte written to the chip and the
first byte is interpreted as an address, the status register (which is
the 16th) is never written.
The other problem is, that initializing all registers to zero is not
valid for day, date and month register. Funny enough this is checked by
ds1337_detect(), which depends on this values not being zero. So then
treated by ds1337_init_client() the ds1337 is not detected anymore,
whereas the failure bit in the status register is still set.

Broken by commit f9e8957937ebf60d22732a5ca9130f48a7603f60 (2.6.16-rc1,
2006-01-06). This fix is in Linus' tree since 2.6.20-rc1 (commit
763d9c046a2e511ec090a8986d3f85edf7448e7e).

Signed-off-by: Dirk Stieler <[email protected]>
Signed-off-by: Dirk Eibach <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/i2c/chips/ds1337.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- linux-2.6.18.7.orig/drivers/i2c/chips/ds1337.c
+++ linux-2.6.18.7/drivers/i2c/chips/ds1337.c
@@ -347,13 +347,19 @@ static void ds1337_init_client(struct i2

if ((status & 0x80) || (control & 0x80)) {
/* RTC not running */
- u8 buf[16];
+ u8 buf[1+16]; /* First byte is interpreted as address */
struct i2c_msg msg[1];

dev_dbg(&client->dev, "%s: RTC not running!\n", __FUNCTION__);

/* Initialize all, including STATUS and CONTROL to zero */
memset(buf, 0, sizeof(buf));
+
+ /* Write valid values in the date/time registers */
+ buf[1+DS1337_REG_DAY] = 1;
+ buf[1+DS1337_REG_DATE] = 1;
+ buf[1+DS1337_REG_MONTH] = 1;
+
msg[0].addr = client->addr;
msg[0].flags = 0;
msg[0].len = sizeof(buf);

--

2007-02-21 01:54:34

by Greg KH

[permalink] [raw]
Subject: [patch 18/18] x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should be accepted

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

------------------
From: "Paolo 'Blaisorblade' Giarrusso" <[email protected]>

Also PTRACE_OLDSETOPTIONS should be accepted, as done by kernel/ptrace.c and
forced by binary compatibility. UML/32bit breaks because of this - since it is wise
enough to use PTRACE_OLDSETOPTIONS to be binary compatible with 2.4 host
kernels.

Until 2.6.17 (commit f0f2d6536e3515b5b1b7ae97dc8f176860c8c2ce) we had:

default:
return sys_ptrace(request, pid, addr, data);

Instead here we have:
case PTRACE_GET_THREAD_AREA:
case ...:
return sys_ptrace(request, pid, addr, data);

default:
return -EINVAL;

This change was a style change - when a case is added, it must be explicitly
tested this way. In this case, not enough testing was done.

Cc: Andi Kleen <[email protected]>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86_64/ia32/ptrace32.c | 1 +
1 file changed, 1 insertion(+)

--- linux-2.6.18.7.orig/arch/x86_64/ia32/ptrace32.c
+++ linux-2.6.18.7/arch/x86_64/ia32/ptrace32.c
@@ -239,6 +239,7 @@ asmlinkage long sys32_ptrace(long reques
case PTRACE_SINGLESTEP:
case PTRACE_DETACH:
case PTRACE_SYSCALL:
+ case PTRACE_OLDSETOPTIONS:
case PTRACE_SETOPTIONS:
return sys_ptrace(request, pid, addr, data);


--

2007-02-21 01:55:07

by Greg KH

[permalink] [raw]
Subject: [patch 11/18] v4l: cx2341x audio_properties is an u16, not u8

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

------------------
From: Hans Verkuil <[email protected]>

This bug broke the MPEG audio mode controls.

(cherry picked from commit cb2c7b4927c8f376b7ba9557978d8c59ed472664)

Signed-off-by: Hans Verkuil <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/media/cx2341x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.18.7.orig/include/media/cx2341x.h
+++ linux-2.6.18.7/include/media/cx2341x.h
@@ -49,7 +49,7 @@ struct cx2341x_mpeg_params {
enum v4l2_mpeg_audio_mode_extension audio_mode_extension;
enum v4l2_mpeg_audio_emphasis audio_emphasis;
enum v4l2_mpeg_audio_crc audio_crc;
- u8 audio_properties;
+ u16 audio_properties;

/* video */
enum v4l2_mpeg_video_encoding video_encoding;

--

2007-02-21 01:55:37

by Greg KH

[permalink] [raw]
Subject: [patch 15/18] V4L: fix ks0127 status flags

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

------------------
From: Martin Samuelsson <[email protected]>

Or status flags together in DECODER_GET_STATUS instead of and-zapping them.

(cherry picked from commit 55d5440d4587454628a850ce26703639885af678)

Signed-off-by: Martin Samuelsson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Michael Krufky <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/media/video/ks0127.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.18.7.orig/drivers/media/video/ks0127.c
+++ linux-2.6.18.7/drivers/media/video/ks0127.c
@@ -712,13 +712,13 @@ static int ks0127_command(struct i2c_cli
*iarg = 0;
status = ks0127_read(ks, KS_STAT);
if (!(status & 0x20)) /* NOVID not set */
- *iarg = (*iarg & DECODER_STATUS_GOOD);
+ *iarg = (*iarg | DECODER_STATUS_GOOD);
if ((status & 0x01)) /* CLOCK set */
- *iarg = (*iarg & DECODER_STATUS_COLOR);
+ *iarg = (*iarg | DECODER_STATUS_COLOR);
if ((status & 0x08)) /* PALDET set */
- *iarg = (*iarg & DECODER_STATUS_PAL);
+ *iarg = (*iarg | DECODER_STATUS_PAL);
else
- *iarg = (*iarg & DECODER_STATUS_NTSC);
+ *iarg = (*iarg | DECODER_STATUS_NTSC);
break;

//Catch any unknown command

--

2007-02-21 01:56:42

by Greg KH

[permalink] [raw]
Subject: [patch 08/18] hfs_fill_super returns success even if no root inode (CVE-2006-6056)

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

------------------
From: Eric Sandeen <[email protected]>

http://kernelfun.blogspot.com/2006/11/mokb-14-11-2006-linux-26x-selinux.html

mount that image...
fs: filesystem was not cleanly unmounted, running fsck.hfs is recommended. mounting read-only.
hfs: get root inode failed.
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000018
printing eip
...
EIP is at superblock_doinit+0x21/0x767
...
[] selinux_sb_kern_mount+0xc/0x4b
[] vfs_kern_mount+0x99/0xf6
[] do_kern_mount+0x2d/0x3e
[] do_mount+0x5fa/0x66d
[] sys_mount+0x77/0xae
[] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb

hfs_fill_super() returns success even if
root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
or
sb->s_root = d_alloc_root(root_inode);

fails. This superblock finds its way to superblock_doinit() which does:

struct dentry *root = sb->s_root;
struct inode *inode = root->d_inode;

and boom. Need to make sure the error cases return an error, I think.

[[email protected]: return -ENOMEM on oom]
Signed-off-by: Eric Sandeen <[email protected]>
Cc: Roman Zippel <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Date: Thu, 16 Nov 2006 09:19:22 +0000 (-0800)
Subject: [patch 08/18] [PATCH] hfs_fill_super returns success even if no root inode
X-Git-Tag: v2.6.19
X-Git-Url: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d6ddf55440833fd9404138026af246c51ebeef22

fs/hfs/super.c | 2 ++
1 file changed, 2 insertions(+)

--- linux-2.6.18.7.orig/fs/hfs/super.c
+++ linux-2.6.18.7/fs/hfs/super.c
@@ -391,11 +391,13 @@ static int hfs_fill_super(struct super_b
hfs_find_exit(&fd);
goto bail_no_root;
}
+ res = -EINVAL;
root_inode = hfs_iget(sb, &fd.search_key->cat, &rec);
hfs_find_exit(&fd);
if (!root_inode)
goto bail_no_root;

+ res = -ENOMEM;
sb->s_root = d_alloc_root(root_inode);
if (!sb->s_root)
goto bail_iput;

--

2007-02-21 01:57:01

by Greg KH

[permalink] [raw]
Subject: [patch 07/18] grow_buffers() infinite loop fix (CVE-2006-5757, CVE-2006-6060)

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

------------------
From: Andrew Morton <[email protected]>

If grow_buffers() is for some reason passed a block number which wants to lie
outside the maximum-addressable pagecache range (PAGE_SIZE * 4G bytes) then it
will accidentally truncate `index' and will then instnatiate a page at the
wrong pagecache offset. This causes __getblk_slow() to go into an infinite
loop.

This can happen with corrupted disks, or with software errors elsewhere.

Detect that, and handle it.

Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Chris Wright <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
fs/buffer.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)

--- linux-2.6.18.7.orig/fs/buffer.c
+++ linux-2.6.18.7/fs/buffer.c
@@ -1179,8 +1179,21 @@ grow_buffers(struct block_device *bdev,
} while ((size << sizebits) < PAGE_SIZE);

index = block >> sizebits;
- block = index << sizebits;

+ /*
+ * Check for a block which wants to lie outside our maximum possible
+ * pagecache index. (this comparison is done using sector_t types).
+ */
+ if (unlikely(index != block >> sizebits)) {
+ char b[BDEVNAME_SIZE];
+
+ printk(KERN_ERR "%s: requested out-of-range block %llu for "
+ "device %s\n",
+ __FUNCTION__, (unsigned long long)block,
+ bdevname(bdev, b));
+ return -EIO;
+ }
+ block = index << sizebits;
/* Create a page with the proper size buffers.. */
page = grow_dev_page(bdev, block, index, size);
if (!page)
@@ -1207,12 +1220,16 @@ __getblk_slow(struct block_device *bdev,

for (;;) {
struct buffer_head * bh;
+ int ret;

bh = __find_get_block(bdev, block, size);
if (bh)
return bh;

- if (!grow_buffers(bdev, block, size))
+ ret = grow_buffers(bdev, block, size);
+ if (ret < 0)
+ return NULL;
+ if (ret == 0)
free_more_memory();
}
}

--

2007-02-21 10:00:39

by Giuseppe Bilotta

[permalink] [raw]
Subject: Re: [patch 03/18] Dont leak NT bit into next task

On Wednesday 21 February 2007 02:49, Greg KH wrote:

> /* frame pointer must be last for get_wchan */
> -#define SAVE_CONTEXT "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
> +#define SAVE_CONTEXT "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"

No idea if this is a problem or not, but you forgot a \n after popf.

--
Giuseppe "Oblomov" Bilotta

2007-02-21 11:54:51

by S.Çağlar Onur

[permalink] [raw]
Subject: Re: [patch 00/18] 2.6.18-stable review

21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı:
> Responses should be made by Friday February 23 00:00 UTC. Anything
> received after that time might be too late.

We have still some CVEish patches in our package which maybe you want to
consider adding into -stable.

* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

Cheers
--
S.Çağlar Onur <[email protected]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


Attachments:
(No filename) (949.00 B)
(No filename) (189.00 B)
Download all attachments

2007-02-21 17:14:26

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [patch 03/18] Dont leak NT bit into next task


On Feb 21 2007 11:00, Giuseppe Bilotta wrote:
>On Wednesday 21 February 2007 02:49, Greg KH wrote:
>
>> /* frame pointer must be last for get_wchan */
>> -#define SAVE_CONTEXT "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
>> -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
>> +#define SAVE_CONTEXT "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
>> +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
>
>No idea if this is a problem or not, but you forgot a \n after popf.

It is on the edge. RESTORE_CONTEXT will not be passed any
arguments, so it is the only thing in a single line, and hence
the implicit \n of the source file applies after \t.
But yes, it may be dangerous. Better is an explicit \n or semicolon
after popf.


Jan
--

2007-02-21 17:21:23

by Chuck Ebbert

[permalink] [raw]
Subject: Re: [patch 03/18] Dont leak NT bit into next task

Giuseppe Bilotta wrote:
> On Wednesday 21 February 2007 02:49, Greg KH wrote:
>
>> /* frame pointer must be last for get_wchan */
>> -#define SAVE_CONTEXT "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
>> -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
>> +#define SAVE_CONTEXT "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
>> +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
>
> No idea if this is a problem or not, but you forgot a \n after popf.
>

It's that way in 2.6.21-rc1.

2007-02-21 17:36:46

by Greg KH

[permalink] [raw]
Subject: Re: [stable] [patch 00/18] 2.6.18-stable review

On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??:
> > Responses should be made by Friday February 23 00:00 UTC. Anything
> > received after that time might be too late.
>
> We have still some CVEish patches in our package which maybe you want to
> consider adding into -stable.
>
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

Do you have a pointer to the patches for these fixes anywhere?

And are you sure they are all for 2.6.18? The first one above is for
the 2.4 kernel tree :)

thanks,

greg k-h

2007-02-21 18:30:26

by S.Çağlar Onur

[permalink] [raw]
Subject: Re: [stable] [patch 00/18] 2.6.18-stable review

Hi;

21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??:
> > > Responses should be made by Friday February 23 00:00 UTC. Anything
> > > received after that time might be too late.
> >
> > We have still some CVEish patches in our package which maybe you want to
> > consider adding into -stable.
> >
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
>
> Do you have a pointer to the patches for these fixes anywhere?

http://svn.pardus.org.tr/pardus/2007/kernel/kernel/files/CVE/ has all of them
as you can see some of them backports grabbed from newer kernels/git trees

> And are you sure they are all for 2.6.18? The first one above is for
> the 2.4 kernel tree :)

Yep, but that one still clearly applies on top of 2.6.18.7. I'm not sure they
have _valid cases_, i'm simply following the CVE announcements :)

Cheers
--
S.Çağlar Onur <[email protected]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


Attachments:
(No filename) (1.57 kB)
(No filename) (189.00 B)
Download all attachments

2007-02-21 18:45:11

by Ismail Dönmez

[permalink] [raw]
Subject: Re: [stable] [patch 00/18] 2.6.18-stable review

On Wednesday 21 February 2007 19:34:45 Greg KH wrote:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??:
> > > Responses should be made by Friday February 23 00:00 UTC. Anything
> > > received after that time might be too late.
> >
> > We have still some CVEish patches in our package which maybe you want to
> > consider adding into -stable.
> >
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
>
> Do you have a pointer to the patches for these fixes anywhere?
>
> And are you sure they are all for 2.6.18? The first one above is for
> the 2.4 kernel tree :)

Yep and Mandriva fixed that in their kernel release which is 2.6.x, I mailed
[email protected] about it some time ago, but got no response so far.

Regards,
ismail

--
FFmpeg doxy @ http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs

2007-02-22 01:14:31

by Michael Ira Krufky

[permalink] [raw]
Subject: Re: [patch 13/18] V4L: cx88: Fix lockup on suspend

Greg KH wrote:
> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
> From: Robert Hancock <[email protected]>
>
> Suspending with the cx88xx module loaded causes the system to lock up
> because the cx88_audio_thread kthread was missing a try_to_freeze()
> call, which caused it to go into a tight loop and result in softlockup
> when suspending. Fix that.
>
> (cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09)
>
> Signed-off-by: Robert Hancock <[email protected]>
> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Michael Krufky <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>

Please drop this one... I shouldn't have sent it to 2.6.18.y nor 2.6.19.y ... tree-mixup :-/

Sorry about that...

-Mike Krufky


> ---
> drivers/media/video/cx88/cx88-tvaudio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-tvaudio.c
> +++ linux-2.6.18.7/drivers/media/video/cx88/cx88-tvaudio.c
> @@ -38,6 +38,7 @@
> #include <linux/module.h>
> #include <linux/moduleparam.h>
> #include <linux/errno.h>
> +#include <linux/freezer.h>
> #include <linux/kernel.h>
> #include <linux/slab.h>
> #include <linux/mm.h>
> @@ -979,6 +980,7 @@ int cx88_audio_thread(void *data)
> msleep_interruptible(1000);
> if (kthread_should_stop())
> break;
> + try_to_freeze();
>
> /* just monitor the audio status for now ... */
> memset(&t, 0, sizeof(t));
>
> --

2007-02-22 05:46:50

by Willy Tarreau

[permalink] [raw]
Subject: Re: [stable] [patch 00/18] 2.6.18-stable review

Hi Greg,

On Wed, Feb 21, 2007 at 09:34:45AM -0800, Greg KH wrote:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??:
> > > Responses should be made by Friday February 23 00:00 UTC. Anything
> > > received after that time might be too late.
> >
> > We have still some CVEish patches in our package which maybe you want to
> > consider adding into -stable.
> >
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
>
> Do you have a pointer to the patches for these fixes anywhere?
>
> And are you sure they are all for 2.6.18? The first one above is for
> the 2.4 kernel tree :)

No, in fact the CVE description is not precise enough. Maybe we should
propose an update to Steven, I don't know how CVE descriptions are
supposed to evolve.

The patch merged in 2.4 was a backport by Hugh Dickins of Linus' 2.6 patch,
which itself was composed of three successive fixes :

2f77d107050abc14bc393b34bdb7b91cf670c250
4fb23e439ce09157d64b89a21061b9fc08f2b495
825020c3866e7312947e17a0caa9dd1a5622bafc

I attach all of them to this mail for your convenience. I noticed that
Linus recently applied other changes to mincore, though I'm not sure
they are security-related.

Hoping this helps,
Willy


Attachments:
(No filename) (1.71 kB)
0001-Fix-incorrect-user-space-access-locking-in-mincore.txt (6.54 kB)
0002-Fix-up-mm-mincore.c-error-value-cases.txt (2.44 kB)
0003-PATCH-sys_mincore-s-max-min.txt (857.00 B)
Download all attachments

2007-02-22 15:29:44

by Adrian Bunk

[permalink] [raw]
Subject: Re: [patch 03/18] Dont leak NT bit into next task

On Wed, Feb 21, 2007 at 11:00:15AM +0100, Giuseppe Bilotta wrote:
> On Wednesday 21 February 2007 02:49, Greg KH wrote:
>
> > /* frame pointer must be last for get_wchan */
> > -#define SAVE_CONTEXT "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> > -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
> > +#define SAVE_CONTEXT "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> > +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
>
> No idea if this is a problem or not, but you forgot a \n after popf.

A discussion of this issue is in the thread starting with [1]
(and I'd re-add the \n in -stable kernels with the patch below
(stolen from 2.6.16) no matter what happened in Linus' tree).

> Giuseppe "Oblomov" Bilotta

cu
Adrian

[1] http://lkml.org/lkml/2007/1/8/374


commit e02612a14b2b714e9d231d14c91e729f0f168299
Author: Adrian Bunk <[email protected]>
Date: Tue Jan 9 03:36:59 2007 +0100

x86_64: re-add a newline to RESTORE_CONTEXT

RESTORE_CONTEXT lost a newline:
http://www.mail-archive.com/[email protected]/msg00559.html

Reported by Steven M. Christey.

Signed-off-by: Adrian Bunk <[email protected]>

diff --git a/include/asm-x86_64/system.h b/include/asm-x86_64/system.h
index 7b2c7aa..dacec59 100644
--- a/include/asm-x86_64/system.h
+++ b/include/asm-x86_64/system.h
@@ -21,7 +21,7 @@

/* frame pointer must be last for get_wchan */
#define SAVE_CONTEXT "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
-#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
+#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\n\t"

#define __EXTRA_CLOBBER \
,"rcx","rbx","rdx","r8","r9","r10","r11","r12","r13","r14","r15"

2007-02-22 16:57:00

by Andi Kleen

[permalink] [raw]
Subject: Re: [patch 03/18] Dont leak NT bit into next task

On Thursday 22 February 2007 16:29, Adrian Bunk wrote:
> On Wed, Feb 21, 2007 at 11:00:15AM +0100, Giuseppe Bilotta wrote:
> > On Wednesday 21 February 2007 02:49, Greg KH wrote:
> >
> > > /* frame pointer must be last for get_wchan */
> > > -#define SAVE_CONTEXT "pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> > > -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
> > > +#define SAVE_CONTEXT "pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> > > +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"
> >
> > No idea if this is a problem or not, but you forgot a \n after popf.
>
> A discussion of this issue is in the thread starting with [1]
> (and I'd re-add the \n in -stable kernels with the patch below
> (stolen from 2.6.16) no matter what happened in Linus' tree).

The newline only helps some broken out of tree patches (which I won't name here)
that shouldn't touch this anyways.

-Andi

2007-02-23 05:53:00

by Pavel Machek

[permalink] [raw]
Subject: Re: [patch 01/18] bcm43xx: Fix for oops on resume

Hi!

> -stable review patch. If anyone has any objections, please let us know.
>
> ------------------
> From: Larry Finger <[email protected]>
>
> There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop.
>
> Signed-off-by: Larry Finger <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> drivers/net/wireless/bcm43xx/bcm43xx.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
> +++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
> @@ -21,7 +21,7 @@
> #define PFX KBUILD_MODNAME ": "
>
> #define BCM43xx_SWITCH_CORE_MAX_RETRIES 50
> -#define BCM43xx_IRQWAIT_MAX_RETRIES 50
> +#define BCM43xx_IRQWAIT_MAX_RETRIES 100
>
> #define BCM43xx_IO_SIZE 8192

I'm sorry, but this does not look like fixing an oops. It may make it
go away for you, or make it less probable, but it certainly can't fix
it.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2007-02-23 20:21:47

by Hugh Dickins

[permalink] [raw]
Subject: Re: [patch 00/18] 2.6.18-stable review

On Tue, 20 Feb 2007, Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.18.8 release.
>
> This will be the last release of the 2.6.18-stable series, so if there
> are patches that you feel should be applied to that tree, please let me
> know.
>
> Responses should be made by Friday February 23 00:00 UTC. Anything
> received after that time might be too late.

Sorry I'm late to the party, just climbed through 2000 mails.

I do hope you'll manage an -rc2,
I seem not the only one to notice wanted patches missing.

There's two from 2.6.19-stable that I thought Chris had agreed
for 2.6.18-stable (Linus' mincore and my read_zero_pagealigned);
two that I sent Chris cc stable for 2.6.18-stable on 4th January
(msync and powerpc current); one I know about from 2.6.19-stable
equally desirable in 2.6.18-stable (Badari's shmem_truncate); and
a new one I was waiting to appear in 2.6.21-rc1 before sending
(Tigran's extN noacl umask).

I'm reassembling the six patches against 2.6.18.8-rc1 for these
now (plus a 2.6.19-stable and a 2.6.20-stable for the latter),
will send them to Greg cc stable shortly.

I wonder whether Chris has a tree somewhere, or a mailbox,
containing further goodies which have been missed.

Hugh

2007-02-23 20:41:53

by Chris Wright

[permalink] [raw]
Subject: Re: [stable] [patch 00/18] 2.6.18-stable review

* Hugh Dickins ([email protected]) wrote:
> On Tue, 20 Feb 2007, Greg KH wrote:
> > This is the start of the stable review cycle for the 2.6.18.8 release.
> >
> > This will be the last release of the 2.6.18-stable series, so if there
> > are patches that you feel should be applied to that tree, please let me
> > know.
> >
> > Responses should be made by Friday February 23 00:00 UTC. Anything
> > received after that time might be too late.
>
> Sorry I'm late to the party, just climbed through 2000 mails.
>
> I do hope you'll manage an -rc2,
> I seem not the only one to notice wanted patches missing.
>
> There's two from 2.6.19-stable that I thought Chris had agreed
> for 2.6.18-stable (Linus' mincore and my read_zero_pagealigned);
> two that I sent Chris cc stable for 2.6.18-stable on 4th January
> (msync and powerpc current); one I know about from 2.6.19-stable
> equally desirable in 2.6.18-stable (Badari's shmem_truncate); and
> a new one I was waiting to appear in 2.6.21-rc1 before sending
> (Tigran's extN noacl umask).

Yes, you're right. I've got the first five here, will get those
sorted shortly.

thanks,
-chris

2007-02-23 21:13:25

by Hugh Dickins

[permalink] [raw]
Subject: Re: [stable] [patch 00/18] 2.6.18-stable review

On Fri, 23 Feb 2007, Chris Wright wrote:
> * Hugh Dickins ([email protected]) wrote:
> >
> > There's two from 2.6.19-stable that I thought Chris had agreed
> > for 2.6.18-stable (Linus' mincore and my read_zero_pagealigned);
> > two that I sent Chris cc stable for 2.6.18-stable on 4th January
> > (msync and powerpc current); one I know about from 2.6.19-stable
> > equally desirable in 2.6.18-stable (Badari's shmem_truncate); and
> > a new one I was waiting to appear in 2.6.21-rc1 before sending
> > (Tigran's extN noacl umask).
>
> Yes, you're right. I've got the first five here, will get those
> sorted shortly.

Okay, thanks a lot Chris, I'll minimize the noise and stick to
just sending the .18 .19 .20 versions of the last one (umask).

Hugh

2007-02-23 23:52:23

by Greg KH

[permalink] [raw]
Subject: Re: [patch 13/18] V4L: cx88: Fix lockup on suspend

On Wed, Feb 21, 2007 at 08:14:22PM -0500, Michael Krufky wrote:
> Greg KH wrote:
> > -stable review patch. If anyone has any objections, please let us know.
> >
> > ------------------
> > From: Robert Hancock <[email protected]>
> >
> > Suspending with the cx88xx module loaded causes the system to lock up
> > because the cx88_audio_thread kthread was missing a try_to_freeze()
> > call, which caused it to go into a tight loop and result in softlockup
> > when suspending. Fix that.
> >
> > (cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09)
> >
> > Signed-off-by: Robert Hancock <[email protected]>
> > Signed-off-by: Mauro Carvalho Chehab <[email protected]>
> > Signed-off-by: Michael Krufky <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
>
> Please drop this one... I shouldn't have sent it to 2.6.18.y nor 2.6.19.y ... tree-mixup :-/

Dropped, thanks for letting me know.

greg k-h

2007-02-25 02:30:56

by Larry Finger

[permalink] [raw]
Subject: Re: [patch 01/18] bcm43xx: Fix for oops on resume

Pavel Machek wrote:
> Hi!
>
>> -stable review patch. If anyone has any objections, please let us know.
>>
>> ------------------
>> From: Larry Finger <[email protected]>
>>
>> There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop.
>>
>> Signed-off-by: Larry Finger <[email protected]>
>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>
>> ---
>> drivers/net/wireless/bcm43xx/bcm43xx.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
>> +++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
>> @@ -21,7 +21,7 @@
>> #define PFX KBUILD_MODNAME ": "
>>
>> #define BCM43xx_SWITCH_CORE_MAX_RETRIES 50
>> -#define BCM43xx_IRQWAIT_MAX_RETRIES 50
>> +#define BCM43xx_IRQWAIT_MAX_RETRIES 100
>>
>> #define BCM43xx_IO_SIZE 8192
>
> I'm sorry, but this does not look like fixing an oops. It may make it
> go away for you, or make it less probable, but it certainly can't fix
> it.

Upon resume, it was taking 65 times through the loop, which caused an oops. We think it is due to a
slow-clock setting at that point, but it certainly does get rid of the oops. This change has also
eliminated the odd oops seen by a few users.

Larry

2007-02-25 08:56:51

by Andrew Morton

[permalink] [raw]
Subject: Re: [patch 01/18] bcm43xx: Fix for oops on resume

> On Sat, 24 Feb 2007 20:30:41 -0600 Larry Finger <[email protected]> wrote:
> Pavel Machek wrote:
> > Hi!
> >
> >> -stable review patch. If anyone has any objections, please let us know.
> >>
> >> ------------------
> >> From: Larry Finger <[email protected]>
> >>
> >> There is a kernel oops on bcm43xx when resuming due to an overly tight timeout loop.
> >>
> >> Signed-off-by: Larry Finger <[email protected]>
> >> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >>
> >> ---
> >> drivers/net/wireless/bcm43xx/bcm43xx.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> --- linux-2.6.18.7.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
> >> +++ linux-2.6.18.7/drivers/net/wireless/bcm43xx/bcm43xx.h
> >> @@ -21,7 +21,7 @@
> >> #define PFX KBUILD_MODNAME ": "
> >>
> >> #define BCM43xx_SWITCH_CORE_MAX_RETRIES 50
> >> -#define BCM43xx_IRQWAIT_MAX_RETRIES 50
> >> +#define BCM43xx_IRQWAIT_MAX_RETRIES 100
> >>
> >> #define BCM43xx_IO_SIZE 8192
> >
> > I'm sorry, but this does not look like fixing an oops. It may make it
> > go away for you, or make it less probable, but it certainly can't fix
> > it.
>
> Upon resume, it was taking 65 times through the loop, which caused an oops. We think it is due to a
> slow-clock setting at that point, but it certainly does get rid of the oops. This change has also
> eliminated the odd oops seen by a few users.
>

Pavel's point is that the driver shouldn't oops the kernel if
BCM43xx_IRQWAIT_MAX_RETRIES is exceeded.

Presumably, the driver will oops if bcm43xx_chip_init() fails for other
reasons?

2007-02-26 00:00:25

by Adrian Bunk

[permalink] [raw]
Subject: Re: [stable] [patch 00/18] 2.6.18-stable review

On Wed, Feb 21, 2007 at 09:34:45AM -0800, Greg KH wrote:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazm????t??:
> > > Responses should be made by Friday February 23 00:00 UTC. Anything
> > > received after that time might be too late.
> >
> > We have still some CVEish patches in our package which maybe you want to
> > consider adding into -stable.
> >
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
>
> Do you have a pointer to the patches for these fixes anywhere?
>
> And are you sure they are all for 2.6.18? The first one above is for
> the 2.4 kernel tree :)

Fixed in 2.6.19.2 and 2.6.18.8 (the latter contains a
Signed-off-by: Greg Kroah-Hartman <[email protected]> ;-) ).

> thanks,
>
> greg k-h

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2007-02-26 00:18:26

by Adrian Bunk

[permalink] [raw]
Subject: Re: [patch 00/18] 2.6.18-stable review

On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.Çağlar Onur wrote:
> 21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı:
> > Responses should be made by Friday February 23 00:00 UTC. Anything
> > received after that time might be too late.
>
> We have still some CVEish patches in our package which maybe you want to
> consider adding into -stable.

Below, I'll only look at the 2.6.18, 2.6.19 and 2.6.20 kernels.

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814

fixed in:
- 2.6.18.8
- 2.6.19.2
- 2.6.20

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749

fixed in:
- 2.6.20 (commit dab6df63086762629936e8b89a5984bae39724f6)

missing in:
- 2.6.18
- 2.6.19

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753

fixed in:
- 2.6.20 (commit be6aab0e9fa6d3c6d75aa1e38ac972d8b4ee82b8)

missing in:
- 2.6.18
- 2.6.19

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823

fixed in:
- 2.6.19.2
- 2.6.20

missing in:
- 2.6.18

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053

fixed in:
- 2.6.19.2
- 2.6.20

missing in:
- 2.6.18

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054

fixed in:
- 2.6.19.2
- 2.6.20

missing in:
- 2.6.18

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333

fixed in:
- 2.6.19.1
- 2.6.20

problem not present in:
- 2.6.18

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

fixed in:
- 2.6.19.5

missing in:
- 2.6.18
- 2.6.20

> Cheers

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed