We (the -stable team) are announcing the release of the 2.6.22.8 kernel.
It contains a single security bugfix for the the sound subsystem. There
is potential for local privilege escalation, so all users are certainly
encouraged to upgrade.
I'll also be replying to this message with a copy of the patch between
2.6.22.7 and 2.6.22.8
The updated 2.6.22.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.22.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=summary
thanks,
greg k-h
--------
Makefile | 2 -
sound/core/memalloc.c | 68 ++++++++++++++++++++++++++++----------------------
2 files changed, 40 insertions(+), 30 deletions(-)
Summary of changes from v2.6.22.7 to v2.6.22.8
==============================================
Greg Kroah-Hartman (1):
Linux 2.6.22.8
Takashi Iwai (1):
Convert snd-page-alloc proc file to use seq_file (CVE-2007-4571)
diff --git a/Makefile b/Makefile
index 12edea0..dc7a45d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 22
-EXTRAVERSION = .7
+EXTRAVERSION = .8
NAME = Holy Dancing Manatees, Batman!
# *DOCUMENTATION*
diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c
index f057430..9b5656d 100644
--- a/sound/core/memalloc.c
+++ b/sound/core/memalloc.c
@@ -27,6 +27,7 @@
#include <linux/pci.h>
#include <linux/slab.h>
#include <linux/mm.h>
+#include <linux/seq_file.h>
#include <asm/uaccess.h>
#include <linux/dma-mapping.h>
#include <linux/moduleparam.h>
@@ -481,53 +482,54 @@ static void free_all_reserved_pages(void)
#define SND_MEM_PROC_FILE "driver/snd-page-alloc"
static struct proc_dir_entry *snd_mem_proc;
-static int snd_mem_proc_read(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int snd_mem_proc_read(struct seq_file *seq, void *offset)
{
- int len = 0;
long pages = snd_allocated_pages >> (PAGE_SHIFT-12);
struct snd_mem_list *mem;
int devno;
static char *types[] = { "UNKNOWN", "CONT", "DEV", "DEV-SG", "SBUS" };
mutex_lock(&list_mutex);
- len += snprintf(page + len, count - len,
- "pages : %li bytes (%li pages per %likB)\n",
- pages * PAGE_SIZE, pages, PAGE_SIZE / 1024);
+ seq_printf(seq, "pages : %li bytes (%li pages per %likB)\n",
+ pages * PAGE_SIZE, pages, PAGE_SIZE / 1024);
devno = 0;
list_for_each_entry(mem, &mem_list_head, list) {
devno++;
- len += snprintf(page + len, count - len,
- "buffer %d : ID %08x : type %s\n",
- devno, mem->id, types[mem->buffer.dev.type]);
- len += snprintf(page + len, count - len,
- " addr = 0x%lx, size = %d bytes\n",
- (unsigned long)mem->buffer.addr, (int)mem->buffer.bytes);
+ seq_printf(seq, "buffer %d : ID %08x : type %s\n",
+ devno, mem->id, types[mem->buffer.dev.type]);
+ seq_printf(seq, " addr = 0x%lx, size = %d bytes\n",
+ (unsigned long)mem->buffer.addr,
+ (int)mem->buffer.bytes);
}
mutex_unlock(&list_mutex);
- return len;
+ return 0;
+}
+
+static int snd_mem_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, snd_mem_proc_read, NULL);
}
/* FIXME: for pci only - other bus? */
#ifdef CONFIG_PCI
#define gettoken(bufp) strsep(bufp, " \t\n")
-static int snd_mem_proc_write(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static ssize_t snd_mem_proc_write(struct file *file, const char __user * buffer,
+ size_t count, loff_t * ppos)
{
char buf[128];
char *token, *p;
- if (count > ARRAY_SIZE(buf) - 1)
- count = ARRAY_SIZE(buf) - 1;
+ if (count > sizeof(buf) - 1)
+ return -EINVAL;
if (copy_from_user(buf, buffer, count))
return -EFAULT;
- buf[ARRAY_SIZE(buf) - 1] = '\0';
+ buf[count] = '\0';
p = buf;
token = gettoken(&p);
if (! token || *token == '#')
- return (int)count;
+ return count;
if (strcmp(token, "add") == 0) {
char *endp;
int vendor, device, size, buffers;
@@ -548,7 +550,7 @@ static int snd_mem_proc_write(struct file *file, const char __user *buffer,
(buffers = simple_strtol(token, NULL, 0)) <= 0 ||
buffers > 4) {
printk(KERN_ERR "snd-page-alloc: invalid proc write format\n");
- return (int)count;
+ return count;
}
vendor &= 0xffff;
device &= 0xffff;
@@ -560,7 +562,7 @@ static int snd_mem_proc_write(struct file *file, const char __user *buffer,
if (pci_set_dma_mask(pci, mask) < 0 ||
pci_set_consistent_dma_mask(pci, mask) < 0) {
printk(KERN_ERR "snd-page-alloc: cannot set DMA mask %lx for pci %04x:%04x\n", mask, vendor, device);
- return (int)count;
+ return count;
}
}
for (i = 0; i < buffers; i++) {
@@ -570,7 +572,7 @@ static int snd_mem_proc_write(struct file *file, const char __user *buffer,
size, &dmab) < 0) {
printk(KERN_ERR "snd-page-alloc: cannot allocate buffer pages (size = %d)\n", size);
pci_dev_put(pci);
- return (int)count;
+ return count;
}
snd_dma_reserve_buf(&dmab, snd_dma_pci_buf_id(pci));
}
@@ -596,9 +598,21 @@ static int snd_mem_proc_write(struct file *file, const char __user *buffer,
free_all_reserved_pages();
else
printk(KERN_ERR "snd-page-alloc: invalid proc cmd\n");
- return (int)count;
+ return count;
}
#endif /* CONFIG_PCI */
+
+static const struct file_operations snd_mem_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = snd_mem_proc_open,
+ .read = seq_read,
+#ifdef CONFIG_PCI
+ .write = snd_mem_proc_write,
+#endif
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
#endif /* CONFIG_PROC_FS */
/*
@@ -609,12 +623,8 @@ static int __init snd_mem_init(void)
{
#ifdef CONFIG_PROC_FS
snd_mem_proc = create_proc_entry(SND_MEM_PROC_FILE, 0644, NULL);
- if (snd_mem_proc) {
- snd_mem_proc->read_proc = snd_mem_proc_read;
-#ifdef CONFIG_PCI
- snd_mem_proc->write_proc = snd_mem_proc_write;
-#endif
- }
+ if (snd_mem_proc)
+ snd_mem_proc->proc_fops = &snd_mem_proc_fops;
#endif
return 0;
}
Hi!
the queue for 2.6.22.8 (2.6.22.8-rc1) is for the next release or
thuse paches droped?
--
Thanks,
Oliver
On Tue, Sep 25, 2007 at 06:09:49PM +0200, Oliver Pinter wrote:
> Hi!
>
> the queue for 2.6.22.8 (2.6.22.8-rc1) is for the next release or
> thuse paches droped?
The queue is for the next release, which will be called 2.6.22.9
(hopefully) as a security update caused the 2.6.22.8 release to happen
last evening.
Sorry for any possible confusion.
thanks,
greg k-h
>From my point, sorry for thread hijacking, but I did not have
the upper node anymore.
So, here is something that I think should go into the next 2.6.22.
A proper fix is already in 2.6.23-git-du-jour.
/home/build/rt.jengelh.10.2-i386/var/tmp/kernel-source-2.6.22.7-build
/usr/src/linux-2.6.22.7-13.1/drivers/ata/pata_ali.c:
In function ■ali_init_chipset■:
/home/build/rt.jengelh.10.2-i386/var/tmp/kernel-source-2.6.22.7-build
/usr/src/linux-2.6.22.7-13.1/drivers/ata/pata_ali.c:466:
warning: ■rev■ is used uninitialized in this function
Yes, it is indeed used uninitialized, and that is dangerous,
given that I do have a chipset that uses pata_ali.ko and
currently runs a 'broken' kernel...it has not exploded yet, though.
I could not backport and create a patch because struct pci_dev
does not have the ->revision field in 2.6.22 yet. Ideas?
On Tue, Sep 25, 2007 at 07:03:24PM +0200, Jan Engelhardt wrote:
>
> From my point, sorry for thread hijacking, but I did not have
> the upper node anymore.
>
How hard is it to start a new message? Me thinks you need a new email
client :)
> So, here is something that I think should go into the next 2.6.22.
> A proper fix is already in 2.6.23-git-du-jour.
Feel free to send the patch, with the git commit id of the upstream
commit to the [email protected] address and we will be glad to review it
that way.
thanks,
greg k-h
On Sep 25 2007 10:35, Greg KH wrote:
>On Tue, Sep 25, 2007 at 07:03:24PM +0200, Jan Engelhardt wrote:
>> So, here is something that I think should go into the next 2.6.22.
>> A proper fix is already in 2.6.23-git-du-jour.
>
>Feel free to send the patch, with the git commit id of the upstream
>commit to the [email protected] address and we will be glad to review it
>that way.
'right, it is already in the mainline kernel.
So it's again the suse kernel src rpm that has it screwed up...
another story. Here's your culprit:
libata-update-libata-to-libata-dev-upstream-5ddf.patch
* Replaces ali_init_chipset() with some new bits, essentially
it removes the call to pci_read_config_byte() since the
revision is now found in struct pci_dev->revision
Basically 2.6.23 stuff.
libata-fix-up-build-after-upstream-update.patch
* changes it back to the 2.6.22 api, so that it compiles again.
But only that.
It FORGETS to add pci_read_config_byte() back.
=== libata-fix-up-build-after-upstream-update.patch
>From 54ee7cd26c5e438dc15d13b60c9f8a54ca05e3fb Mon Sep 17 00:00:00 2001
From: Tejun Heo <[email protected]>
Date: Fri, 3 Aug 2007 02:21:51 +0900
Subject: [PATCH] libata: fix up build after upstream update
References: 288078
Signed-off-by: Tejun Heo <[email protected]>
===
The bug is still present in current suse kotd. >:-(
Please fix it there. A cc will go to opensuse-kernel@,
but other than that, I am in the wrong mood right now to do anything.