Add ominkey CVE fix and an old tcp fix

diff --git a/review-2.6.20/fix-buffer-overflow-in-omnikey-cardman-4040-driver.patch b/review-2.6.20/fix-buffer-overflow-in-omnikey-cardman-4040-driver.patch
new file mode 100644 (file)
index 0000000..9f2dab1
--- /dev/null
+++ b/review-2.6.20/fix-buffer-overflow-in-omnikey-cardman-4040-driver.patch
@@ -0,0 +1,46 @@
+From stable-bounces@linux.kernel.org  Wed Mar  7 10:25:30 2007
+Message-ID: <45EF02F0.2040302@redhat.com>
+Date: Wed, 07 Mar 2007 13:22:40 -0500
+From: Chuck Ebbert <cebbert@redhat.com>
+To: linux-stable <stable@kernel.org>
+Subject: Fix buffer overflow in Omnikey CardMan 4040 driver (CVE-2007-0005)
+
+From: Marcel Holtmann <marcel@holtmann.org>
+
+Based on a patch from Don Howard <dhoward@redhat.com>
+
+When calling write() with a buffer larger than 512 bytes, the
+driver's write buffer overflows, allowing to overwrite the EIP and
+execute arbitrary code with kernel privileges.
+
+In read(), there exists a similar problem, but coming from the device.
+A malicous or buggy device sending more than 512 bytes can overflow
+of the driver's read buffer, with the same effects as above.
+
+Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
+Signed-off-by: Harald Welte <laforge@gnumonks.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+---
+ drivers/char/pcmcia/cm4040_cs.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- linux-2.6.20.1.orig/drivers/char/pcmcia/cm4040_cs.c
++++ linux-2.6.20.1/drivers/char/pcmcia/cm4040_cs.c
+@@ -273,6 +273,7 @@ static ssize_t cm4040_read(struct file *
+       DEBUGP(6, dev, "BytesToRead=%lu\n", bytes_to_read);
+ 
+       min_bytes_to_read = min(count, bytes_to_read + 5);
++      min_bytes_to_read = min_t(size_t, min_bytes_to_read, READ_WRITE_BUFFER_SIZE);
+ 
+       DEBUGP(6, dev, "Min=%lu\n", min_bytes_to_read);
+ 
+@@ -340,7 +341,7 @@ static ssize_t cm4040_write(struct file 
+               return 0;
+       }
+ 
+-      if (count < 5) {
++      if ((count < 5) || (count > READ_WRITE_BUFFER_SIZE)) {
+               DEBUGP(2, dev, "<- cm4040_write buffersize=%Zd < 5\n", count);
+               return -EIO;
+       }

diff --git a/review-2.6.20/series b/review-2.6.20/series
index 749ae88ac3ac8bd647e9940973700efa879a92c0..7ee492e3877e091a2d3479aec6578bf324140644 100644 (file)
--- a/review-2.6.20/series
+++ b/review-2.6.20/series
@@ -99,3 +99,5 @@ video-aty-mach64_ct.c-fix-bogus-delay-loop.patch
 pktcdvd-correctly-set-cmd_len-field-in-pkt_generic_packet.patch
 ata-convert-gsi-to-irq-on-ia64.patch
 gfs2-fix-locking-mistake.patch
+tcp-fix-minisock-tcp_create_openreq_child-typo.patch
+fix-buffer-overflow-in-omnikey-cardman-4040-driver.patch

diff --git a/review-2.6.20/tcp-fix-minisock-tcp_create_openreq_child-typo.patch b/review-2.6.20/tcp-fix-minisock-tcp_create_openreq_child-typo.patch
new file mode 100644 (file)
index 0000000..0b06978
--- /dev/null
+++ b/review-2.6.20/tcp-fix-minisock-tcp_create_openreq_child-typo.patch
@@ -0,0 +1,56 @@
+From stable-bounces@linux.kernel.org  Wed Feb 28 11:31:59 2007
+Date: Wed, 28 Feb 2007 11:29:33 -0800 (PST)
+Message-Id: <20070228.112933.41634877.davem@davemloft.net>
+To: stable@kernel.org
+From: David Miller <davem@davemloft.net>
+Cc: bunk@stusta.de
+Subject: TCP: Fix minisock tcp_create_openreq_child() typo.
+
+From: Arnaldo Carvalho de Melo <acme@redhat.com>
+
+On 2/28/07, KOVACS Krisztian <hidden@balabit.hu> wrote:
+>
+>   Hi,
+>
+>   While reading TCP minisock code I've found this suspiciously looking
+> code fragment:
+>
+> - 8< -
+> struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb)
+> {
+>         struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC);
+>
+>         if (newsk != NULL) {
+>                 const struct inet_request_sock *ireq = inet_rsk(req);
+>                 struct tcp_request_sock *treq = tcp_rsk(req);
+>                 struct inet_connection_sock *newicsk = inet_csk(sk);
+>                 struct tcp_sock *newtp;
+> - 8< -
+>
+>   The above code initializes newicsk to inet_csk(sk), isn't that supposed
+> to be inet_csk(newsk)?  As far as I can tell this might leave
+> icsk_ack.last_seg_size zero even if we do have received data.
+
+Good catch!
+
+David, please apply the attached patch.
+
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+
+---
+ net/ipv4/tcp_minisocks.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- linux-2.6.20.1.orig/net/ipv4/tcp_minisocks.c
++++ linux-2.6.20.1/net/ipv4/tcp_minisocks.c
+@@ -381,7 +381,7 @@ struct sock *tcp_create_openreq_child(st
+       if (newsk != NULL) {
+               const struct inet_request_sock *ireq = inet_rsk(req);
+               struct tcp_request_sock *treq = tcp_rsk(req);
+-              struct inet_connection_sock *newicsk = inet_csk(sk);
++              struct inet_connection_sock *newicsk = inet_csk(newsk);
+               struct tcp_sock *newtp;
+ 
+               /* Now setup tcp_sock */