drafting a DSA for 2.6.8

[dann frazier]

In order to hopefully help kickstart the security update process, I've
drafted some DSA text for our sarge/2.6.8 kernels (attached).  Thanks to
Micah, we have CAN IDs assigned for a number of things we just had
marked as security.  I tried to map all of the patches to CANs, but
these are the ones remaining.  Does anyone know if there is a CAN ID for
any of the following?

arch-ia64-ptrace-getregs-putregs.dpatch
arch-x86_64-kernel-smp-boot-race.dpatch
fs-exec-posix-timers-leak-1.dpatch
fs-exec-posix-timers-leak-2.dpatch
net-bridge-forwarding-poison-1.dpatch
net-bridge-forwarding-poison-2.dpatch
net-bridge-mangle-oops-1.dpatch
net-bridge-mangle-oops-2.dpatch
net-bridge-netfilter-etables-smp-race.dpatch
net-ipv4-ipvs-conn_tab-race.dpatch
net-netlink-autobind-return.dpatch
net-rose-ndigis-verify.dpatch
netfilter-NAT-memory-corruption.dpatch
netfilter-ip_conntrack_untracked-refcount.dpatch
ppc32-time_offset-misuse.dpatch
sound-usb-usbaudio-unplug-oops.dpatch
sys_get_thread_area-leak.dpatch

-- 
dann frazier <[EMAIL PROTECTED]>
Packages   : kernel-source-2.6.8
 kernel-image-2.6.8-alpha
 kernel-image-2.6.8-amd64
 kernel-image-2.6.8-hppa
 kernel-image-2.6.8-i386
 kernel-image-2.6.8-ia64
 kernel-image-2.6.8-m68k
 kernel-image-2.6.8-s390
 kernel-image-2.6.8-sparc
 kernel-patch-2.6.8-powerpc
Vulnerability  : multiple
Problem type   : remote, local, DoS
Debian-specific: no
CVE Id(s)  : CAN-2005-3105 CAN-2005-1763 CAN-2005-1762 CAN-2005-0756
 CAN-2005-3108 CAN-2005-3106 CAN-2005-3107 CAN-2005-3109
 CAN-2005-1265 CAN-2005-0757 CAN-2005-1765 CAN-2005-1761
 CAN-2005-2548 CAN-2004-2302 CAN-2005-1767 CAN-2005-2458
 CAN-2005-2459 CAN-2005-2456 CAN-2005-2872 CAN-2005-2801

Multiple security vulnerabilities have been identified in the Linux kernel.
These vulnerabilities could allow an attacker to execute arbitrary code or
initiate a denial of service (DoS) attack.


CAN-2005-3105

The mprotect code (mprotect.c) in Linux 2.6 on Itanium IA64 Montecito
processors does not properly maintain cache coherency as required by
the architecture, which allows local users to cause a denial of service
and possibly corrupt data by modifying PTE protections.

CAN-2005-1763

Buffer overflow in ptrace in the Linux Kernel for 64-bit architectures
allows local users to write bytes into kernel memory.

CAN-2005-1762

The ptrace call in the Linux kernel 2.6.8.1 and 2.6.10 for the AMD64
platform allows local users to cause a denial of service (kernel crash)
via a "non-canonical" address.

CAN-2005-0756

ptrace 2.6.8.1 does not properly verify addresses on the amd64
platform, which allows local users to cause a denial of service (kernel
crash)

CAN-2005-3108

mm/ioremap.c in Linux 2.6 on 64-bit x86 systems allows local users to
cause a denial of service or an information leak via an iremap on a
certain memory map that causes the iounmap to perform a lookup of a
page that does not exist.

CAN-2005-3106

Race condition in Linux 2.6, when threads are sharing memory mapping
via CLONE_VM (such as linuxthreads and vfork), might allow local users
to cause a denial of service (deadlock) by triggering a core dump while
waiting for a thread that has just performed an exec.

CAN-2005-3107

fs/exec.c in Linux 2.6, when one thread is tracing another thread that
shares the same memory map, might allow local users to cause a denial
of service (deadlock) by forcing a core dump when the traced thread is
in the TASK_TRACED state.

CAN-2005-3109

The HFS and HFS+ (hfsplus) modules in Linux 2.6 allows attackers to
cause a denial of service (oops) by using hfsplus to mount a filesystem
that is not hfsplus.

CAN-2005-1265

The mmap function in the Linux Kernel 2.6.10 can be used to create
memory maps with a start address beyond the end address, which allows
local users to cause a denial of service (kernel crash).

CAN-2005-0757

The xattr file system code, as backported in Red Hat Enterprise Linux 3
on 64-bit systems, does not properly handle certain offsets, which
allows local users to cause a denial of service (system crash) via
certain actions on an ext3 file system with extended attributes
enabled.

CAN-2005-1765

syscall in the Linux kernel 2.6.8.1 and 2.6.10 for the AMD64 platform,
when running in 32-bit compatibility mode, allows local users to cause
a denial of service (kernel hang) via crafted arguments.

CAN-2005-1761

Linux kernel 2.6 and 2.4 on the IA64 architecture allows local users to
cause a denial of service (kernel crash) via pt

Bug#332569: kernel-source-2.4.27: [CAN-2005-3105] [IA64] Montecito CPU local DoS

[Horms]

Package: kernel-source-2.4.27
Version: 2.4.27-11
Severity: important
Tags: patch security


It appears that 2.4.27 is vulnerable to CAN-2005-3105,
which has long been fixed in Debian's 2.6

Dann, can you take a look into this?

CAN stuff is below for reference, though the patch came from
you in the first place.

andidate: CAN-2005-3105
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-3105
Final-Decision:
Interim-Decision:
Modified:
Proposed:
Assigned: 20050930
Category: SF
Reference:
MISC:http://www.intel.com/cd/ids/developer/asmo-na/eng/215766.htm
Reference:
MISC:http://cache-www.intel.com/cd/00/00/21/57/215792_215792.pdf
Reference:
CONFIRM:http://linux.bkbits.net:8080/linux-2.6/[EMAIL 
PROTECTED]|src/|src/mm|related/mm/mprotect.c

The mrpotect code (mprotect.c) in Linux 2.6 on Itanium IA64 Montecito
processors does not properly maintain cache coherency as required by
the architecture, which allows local users to cause a denial of
service and possibly corrupt data by modifying PTE protections.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686-smp
Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP (charmap=EUC-JP) (ignored: 
LC_ALL set to ja_JP.eucJP)

Versions of packages kernel-source-2.4.27 depends on:
ii  binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
ii  bzip21.0.2-10high-quality block-sorting file co
ii  coreutils [fileutils 5.2.1-2.1   The GNU core utilities
ii  fileutils5.2.1-2.1   The GNU file management utilities 

Versions of packages kernel-source-2.4.27 recommends:
ii  gcc-3.3   1:3.3.6-10 The GNU C compiler
ii  libc6-dev [libc-dev]  2.3.5-6GNU C Library: Development Librari
ii  make  3.80-11The GNU version of the "make" util

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332559: kernel-image-2.6.8-2-686: Serial not working

[Horms]

On Thu, Oct 06, 2005 at 10:27:24PM -0500, root wrote:
> Package: kernel-image-2.6.8-2-686
> Version: 2.6.8-16
> Severity: important
> 
> 
> Classified 'important' as the 2.6 kernel package will not work with
> console=/dev/ttyS0,19200n8.
> 
> Verified to be a kernel issue by using the 2.4.27-2 package with
> identical configuration.
> 
> System runs on a PIIX4 chipset, with a serial console supported by the
> bios.  
> 
> Minicom was used to test the link, and does not work in 2.6, but does in
> 2.4.  The login prompt and all data after entering the initrd is
> garbage.

Is it possible to test the 2.6.26-5.99.sarge1 backport packages at
http://packages.vergenet.net/testing/linux-2.6/ to see if the problem
has been resolved upstream between 2.6.8 and 2.6.12.

Thanks

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [PATCH] hfs, hfsplus: don't leak s_fs_info and fix an oops

[Horms]

I have been looking over CAN-2005-3109, better known as
the hfs, hfsplus leak and oops, and I am wondering if the 
problem is present in 2.4

I took a look at making a backport, and it seems that
some of the problems are there, but without a deeper inspection
of the code its difficult to tell if the problems manifest or not.

For reference, here is the 2.6 variant of the change:
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=945b092011c6af71a0107be96e119c8c08776f3f

I can futher my backport effort and post it for inspection if need be.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332559: kernel-image-2.6.8-2-686: Serial not working

[root]

Package: kernel-image-2.6.8-2-686
Version: 2.6.8-16
Severity: important


Classified 'important' as the 2.6 kernel package will not work with
console=/dev/ttyS0,19200n8.

Verified to be a kernel issue by using the 2.4.27-2 package with
identical configuration.

System runs on a PIIX4 chipset, with a serial console supported by the
bios.  

Minicom was used to test the link, and does not work in 2.6, but does in
2.4.  The login prompt and all data after entering the initrd is
garbage.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages kernel-image-2.6.8-2-686 depends on:
ii  coreutils [fileutils] 5.2.1-2The GNU core utilities
ii  initrd-tools  0.1.81.1   tools to create initrd image for p
ii  module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: d-i tag removal

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # I decided to remove the d-i tag from all packages maintained by the
> # d-i team, so the list of d-i tagged bugs reduces to bugs that affect
> # d-i but are not in d-i itself
> tag 328992 - d-i
Bug#328992: partconf: [s/390] No longer recognizes dasd partitions
Tags were: d-i
Tags removed: d-i

> tag 329391 - d-i
Bug#329391: no longer seems to work
Tags were: d-i
Tags removed: d-i

> tag 224641 - d-i
Bug#224641: grub-installer does not account for serial console
Tags were: patch d-i
Tags removed: d-i

> tag 213482 - d-i
Bug#213482: cdebconf - allocate fd 3 always or use dynamicaly assigned fd
Tags were: d-i
Tags removed: d-i

> tag 220282 - d-i
Bug#220282: partconf: should apt-install userspace tools for created filesystems
Tags were: d-i
Tags removed: d-i

> tag 222718 - d-i
Bug#222718: re-running menu item is a trap you cannot get out of
Tags were: d-i
Tags removed: d-i

> tag 243373 - d-i
Bug#243373: newt frontend replaces any line starting with a non-breaking space 
with a blank line, unless in utf-8 locale
Tags were: d-i
Tags removed: d-i

> tag 274307 - d-i
Bug#274307: partman-ext3 not available in lowmem level 2
Tags were: d-i
Tags removed: d-i

> tag 276726 - d-i
Bug#276726: bootprompt buffer size
Tags were: d-i sarge
Tags removed: d-i

> tag 283712 - d-i
Bug#283712: Installation Report (Reboot from USB Hard Disk failed)
Tags were: d-i
Tags removed: d-i

> tag 284736 - d-i
Bug#284736: install: Installer overwrites user data without warning
Tags were: d-i
Tags removed: d-i

> tag 292570 - d-i
Bug#292570: [hppa][2005week3][install report] installer in sarge unusable on 
HPPA
Tags were: d-i
Tags removed: d-i

> tag 317062 - d-i
Bug#317062: umount -a hangs in strcmp with 2.6.11/12
Tags were: d-i
Tags removed: d-i

> tag 258834 - d-i
Bug#258834: failed to create partitions
Tags were: moreinfo d-i
Tags removed: d-i

> tag 201396 - d-i
Bug#201396: anna: udebs in udeb_exclude will be installed anyway
Tags were: patch d-i
Tags removed: d-i

> tag 220269 - d-i
Bug#220269: base-config: should use d-i's apt config
Tags were: patch d-i
Bug#252121: Should pre-seed Base-config templates with mirror location and 
mirror settings
Tags removed: d-i

> tag 252121 - d-i
Bug#252121: Should pre-seed Base-config templates with mirror location and 
mirror settings
Tags were: patch
Bug#220269: base-config: should use d-i's apt config
Tags removed: d-i

> tag 291723 - d-i
Bug#291723: kde-i18-bg for cyrillic-desktop
Tags were: d-i patch
Tags removed: d-i

> tag 218598 - d-i
Bug#218598: partconf and partitioner use varying ways of describing the same 
disks
Tags were: confirmed d-i
Tags removed: d-i

> tag 218598 - d-i
Bug#218598: partconf and partitioner use varying ways of describing the same 
disks
Tags were: confirmed
Tags removed: d-i

> tag 157888 - d-i
Bug#157888: (c)debconf-copydb: do not handle --config=Foo:bar
Tags were: d-i
Tags removed: d-i

> tag 183366 - d-i
Bug#183366: lilo-installer: Installation fail to boot on machine with HD on hdd
Tags were: d-i
Tags removed: d-i

> tag 196033 - d-i
Bug#196033: No _meaningful_ feedback when debootstrap fails
Tags were: d-i
Tags removed: d-i

> tag 200467 - d-i
Bug#200467: debian-installer: Hardware detection should not fail when all 
required modules are included in kernel
Tags were: d-i
Tags removed: d-i

> tag 201252 - d-i
Bug#201252: anna: "No installer modules found" the second time you load modules
Tags were: d-i
Tags removed: d-i

> tag 205519 - d-i
Bug#205519: installation: Wrong error message when disk is full
Tags were: d-i
Tags removed: d-i

> tag 211147 - d-i
Bug#211147: lilo(?) install fails; reboot after "booting the kernel"
Tags were: d-i
Tags removed: d-i

> tag 212442 - d-i
Bug#212442: autopartkit failure (with mounted partitions and swap)
Tags were: d-i
Tags removed: d-i

> tag 213834 - d-i
Bug#213834: depends on libc-udeb
Tags were: d-i
Tags removed: d-i

> tag 215471 - d-i
Bug#215471: failure report; exit 11 with errors about scsi io errors on 
non-scsi system
Tags were: d-i
Tags removed: d-i

> tag 215473 - d-i
Bug#215473: generated fstab does not take ide-scsi into account
Tags were: d-i
Tags removed: d-i

> tag 216711 - d-i
Bug#216711: autopartkit has problems with a not present removable drive
Tags were: d-i
Tags removed: d-i

> tag 217503 - d-i
Bug#217503: Evil autopartkit should _NEVER_ _NEVER_ try to overwrite an unknown 
partition table
Tags were: d-i
Tags removed: d-i

> tag 218485 - d-i
Bug#218485: hangs eating memory in pt_BR locale in xterm
Tags were: d-i
Tags removed: d-i

> tag 218610 - d-i
Bug#218610: partconf: Skipping to the next partition in the list would be better
Tags were: d-i
Tags removed: d-i

> tag 218765 - d-i
Bug#218765: partconf: swap is mounted as "/"
Tags were: d-i
Bug#220825: partconf: should not assign a mountpoint to swap partitions
Bug#238292: The user had to umount the swap
Tags removed: d-i

> tag 220483 - d-i
Bug#220483: partitioner: passed a unpartitionable harddisk to c

linux-2.6_2.6.13-1_i386.changes is NEW

[Debian Installer]

kernel-image-2.6-386_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-386_2.6.13-1_i386.deb
kernel-image-2.6-686-smp_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-686-smp_2.6.13-1_i386.deb
kernel-image-2.6-686_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-686_2.6.13-1_i386.deb
kernel-image-2.6-k7-smp_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-k7-smp_2.6.13-1_i386.deb
kernel-image-2.6-k7_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/kernel-image-2.6-k7_2.6.13-1_i386.deb
linux-2.6_2.6.13-1.diff.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.13-1.diff.gz
linux-2.6_2.6.13-1.dsc
  to pool/main/l/linux-2.6/linux-2.6_2.6.13-1.dsc
linux-2.6_2.6.13.orig.tar.gz
  to pool/main/l/linux-2.6/linux-2.6_2.6.13.orig.tar.gz
(new) linux-doc-2.6.13_2.6.13-1_all.deb optional doc
Linux kernel specific documentation for version 2.6.13
 This package provides the various README files and HTML documentation for
 the Linux kernel version 2.6.13. Plenty of information, including the
 descriptions of varios kernel subsystems, filesystems, driver-specific
 notes and the like.  Consult the file
 .
 /usr/share/doc/linux-doc-2.6.13/Documentation/00-INDEX
 .
 for the detailed description of the contents.
 .
 This packages is produced using an updated kernel packaging system and
 replaces older kernel-doc packages
linux-headers-2.6-386_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-386_2.6.13-1_i386.deb
linux-headers-2.6-686-smp_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-686-smp_2.6.13-1_i386.deb
linux-headers-2.6-686_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-686_2.6.13-1_i386.deb
linux-headers-2.6-k7-smp_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-k7-smp_2.6.13-1_i386.deb
linux-headers-2.6-k7_2.6.13-1_i386.deb
  to pool/main/l/linux-2.6/linux-headers-2.6-k7_2.6.13-1_i386.deb
(new) linux-headers-2.6.13-1-386_2.6.13-1_i386.deb optional devel
Header files for Linux kernel 2.6.13 on 386-class machines
 This package provides the architecture-specific kernel header files for
 Linux kernel 2.6.13 on 386-class machines, generally used for building
 out-of-tree kernel modules.  These files are going to be installed into
 /usr/src/linux-headers-2.6.13-1-386, and can be used for building modules
 that load into the kernel provided by the linux-image-2.6.13-1-386
 package.
 .
 This packages is produced using an updated kernel packaging system and
 replaces older kernel-headers packages
(new) linux-headers-2.6.13-1-686-smp_2.6.13-1_i386.deb optional devel
Header files for Linux kernel 2.6.13 on PPro/Celeron/PII/PIII/P4 SMP machines
 This package provides the architecture-specific kernel header files for
 Linux kernel 2.6.13 on multi-processor Pentium Pro/Celeron/Pentium
 II/Pentium III/Pentium 4 machines, generally used for building out-of-tree
 kernel modules.  These files are going to be installed into
 /usr/src/linux-headers-2.6.13-1-686-smp, and can be used for building
 modules that load into the kernel provided by the
 linux-image-2.6.13-1-686-smp package.
 .
 This packages is produced using an updated kernel packaging system and
 replaces older kernel-headers packages
(new) linux-headers-2.6.13-1-686_2.6.13-1_i386.deb optional devel
Header files for Linux kernel 2.6.13 on PPro/Celeron/PII/PIII/P4 machines
 This package provides the architecture-specific kernel header files for
 Linux kernel 2.6.13 on Pentium Pro/Celeron/Pentium II/Pentium III/Pentium
 4 machines, generally used for building out-of-tree kernel modules.  These
 files are going to be installed into /usr/src/linux-headers-2.6.13-1-686,
 and can be used for building modules that load into the kernel provided by
 the linux-image-2.6.13-1-686 package.
 .
 This packages is produced using an updated kernel packaging system and
 replaces older kernel-headers packages
(new) linux-headers-2.6.13-1-k7-smp_2.6.13-1_i386.deb optional devel
Header files for Linux kernel 2.6.13 on AMD K7 SMP machines
 This package provides the architecture-specific kernel header files for
 Linux kernel 2.6.13 on 32-bit multi-processor AMD Duron/Athlon/AthlonXP
 machines, generally used for building out-of-tree kernel modules.  These
 files are going to be installed into
 /usr/src/linux-headers-2.6.13-1-k7-smp, and can be used for building
 modules that load into the kernel provided by the
 linux-image-2.6.13-1-k7-smp package.
 .
 This packages is produced using an updated kernel packaging system and
 replaces older kernel-headers packages
(new) linux-headers-2.6.13-1-k7_2.6.13-1_i386.deb optional devel
Header files for Linux kernel 2.6.13 on AMD K7 machines
 This package provides the architecture-specific kernel header files for
 Linux kernel 2.6.13 on 32bit AMD Duron/Athlon/AthlonXP machines, generally
 used for building out-of-tree kernel modules.  These files are going to be
 installed into /usr/src/linux-headers-2.6.13-1-k7, and can be used for
 building modules that load in

Processing of linux-2.6_2.6.13-1_i386.changes

[Archive Administrator]

linux-2.6_2.6.13-1_i386.changes uploaded successfully to localhost
along with the files:
  linux-2.6_2.6.13-1.dsc
  linux-2.6_2.6.13.orig.tar.gz
  linux-2.6_2.6.13-1.diff.gz
  linux-doc-2.6.13_2.6.13-1_all.deb
  linux-manual-2.6.13_2.6.13-1_all.deb
  linux-patch-debian-2.6.13_2.6.13-1_all.deb
  linux-source-2.6.13_2.6.13-1_all.deb
  linux-tree-2.6.13_2.6.13-1_all.deb
  linux-headers-2.6.13_2.6.13-1_i386.deb
  linux-headers-2.6.13-1_2.6.13-1_i386.deb
  linux-headers-2.6.13-1-386_2.6.13-1_i386.deb
  linux-image-2.6.13-1-386_2.6.13-1_i386.deb
  linux-image-386_2.6.13-1_i386.deb
  linux-image-2.6-386_2.6.13-1_i386.deb
  linux-headers-2.6-386_2.6.13-1_i386.deb
  linux-headers-2.6.13-1-686_2.6.13-1_i386.deb
  linux-image-2.6.13-1-686_2.6.13-1_i386.deb
  linux-image-686_2.6.13-1_i386.deb
  linux-image-2.6-686_2.6.13-1_i386.deb
  linux-headers-2.6-686_2.6.13-1_i386.deb
  linux-headers-2.6.13-1-686-smp_2.6.13-1_i386.deb
  linux-image-2.6.13-1-686-smp_2.6.13-1_i386.deb
  linux-image-686-smp_2.6.13-1_i386.deb
  linux-image-2.6-686-smp_2.6.13-1_i386.deb
  linux-headers-2.6-686-smp_2.6.13-1_i386.deb
  linux-headers-2.6.13-1-k7_2.6.13-1_i386.deb
  linux-image-2.6.13-1-k7_2.6.13-1_i386.deb
  linux-image-k7_2.6.13-1_i386.deb
  linux-image-2.6-k7_2.6.13-1_i386.deb
  linux-headers-2.6-k7_2.6.13-1_i386.deb
  linux-headers-2.6.13-1-k7-smp_2.6.13-1_i386.deb
  linux-image-2.6.13-1-k7-smp_2.6.13-1_i386.deb
  linux-image-k7-smp_2.6.13-1_i386.deb
  linux-image-2.6-k7-smp_2.6.13-1_i386.deb
  linux-headers-2.6-k7-smp_2.6.13-1_i386.deb
  kernel-image-2.6-386_2.6.13-1_i386.deb
  kernel-image-2.6-686_2.6.13-1_i386.deb
  kernel-image-2.6-686-smp_2.6.13-1_i386.deb
  kernel-image-2.6-k7_2.6.13-1_i386.deb
  kernel-image-2.6-k7-smp_2.6.13-1_i386.deb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian.kernel.net archive for security updates & other stuff

[Horms]

On Thu, Oct 06, 2005 at 07:37:36PM -0600, dann frazier wrote:
> Unified Repository for Proposed Kernel Security Updates
> ---
> I've created a unified archive for our proposed security updates for
> sarge.  Hopefully this will make it easier for users to test/use these
> builds, as well as provide a single location for the security team to
> pick them up.
> 
> This archive will soon be available at:
>   deb http://kernel.debian.net/debian sarge/updates main
> 
> But until alioth has the alias configured, use kernel.alioth.debian.org
> instead.  The debian.net url should give us more flexibility should we
> decide to relocate the archive at some point.
> 
> Please let me know soon if there's anything you'd like to see changed.
> I'd like to announce this more broadly RSN.  (For instance, should the
> dist be sarge/updates?  Maybe sarge-proposed-updates or sarge-security?)
> 
> Managing the Archive
> 
> I've created a simple archive management system to hopefully make it
> easy/efficient to manage.  It sits in the root of the archive tree:
> alioth.debian.org:/org/alioth.debian.org/chroot/home/groups/kernel/htdocs/debian
> 
> The contents of each dist is maintained in a 'pkglist' file.
> (sarge/updates is the only dist at the moment).  pkglist files just
> contain a list of .changes files to include.  A toplevel Makefile
> processes these files, creates the dists/ hierarchy, and finally runs
> apt-ftparchive generate.
> 
> This should make it easy to quickly add dists and share packages between
> them.  Say, sarge-proposed-updates or sarge-backports.  (Not that we
> shouldn't use backports.org or volatile where appropriate, of course).
> We could store these pkglists in svn at some point, should we want
> revision control on the archive.

Thanks Dann, that is awsome. I'm currently trying to get 2.6.8 and 
2.4.27 up to date again. Once thats done I'll make a sarge2 upload
source, i386 and powerpc upload. We can take other architectues from 
there.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd-tools and booting root on lvm with new kernel

[Horms]

On Thu, Oct 06, 2005 at 07:58:10PM +0200, Sven Luther wrote:
> On Thu, Oct 06, 2005 at 07:31:18PM +0200, Maximilian Attems wrote:
> > On Thu, Oct 06, 2005 at 06:58:55PM +0200, Sven Luther wrote:
> >  
> > > Do you have a link to it ? And does it support using yaird as alternative 
> > > ? Or
> > > running initrd 2.4 or pre-2.6.12 kernels ?
> > 
> > it's supporting initrd-tools on hppa and ia64 afaik.
> >  
> > > The above proposal works with kernel-package just fine.
> > 
> > ok so i misunderstood you.
> >  
> > > > my proposal is just to localize changes, so that we clearly know,
> > > > what broke?
> > > > 
> > > > releasing a new upstream version and changing the early boot stuff
> > > > in the same time needs to be avoided.
> > > 
> > > I don't follow you on this.
> > 
> > the idea is to to have early boot change without any other bunch of
> > usual fixes and changes. they would be noise for that transition.
> 
> I higlhly oppose doing a 2.6.13-2 upload just for that, it would be a giant
> waste of auto-builder time.
> 
> 
> Oh well, i guess it will be no worse than previous failed upload attempts ...

I have uploaded 2.6.13-1 now. I am pretty sure it will FTBFS on
many architectues. So lets spin -2 some time soon.



-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

debian.kernel.net archive for security updates & other stuff

[dann frazier]

Unified Repository for Proposed Kernel Security Updates
---
I've created a unified archive for our proposed security updates for
sarge.  Hopefully this will make it easier for users to test/use these
builds, as well as provide a single location for the security team to
pick them up.

This archive will soon be available at:
  deb http://kernel.debian.net/debian sarge/updates main

But until alioth has the alias configured, use kernel.alioth.debian.org
instead.  The debian.net url should give us more flexibility should we
decide to relocate the archive at some point.

Please let me know soon if there's anything you'd like to see changed.
I'd like to announce this more broadly RSN.  (For instance, should the
dist be sarge/updates?  Maybe sarge-proposed-updates or sarge-security?)

Managing the Archive

I've created a simple archive management system to hopefully make it
easy/efficient to manage.  It sits in the root of the archive tree:
alioth.debian.org:/org/alioth.debian.org/chroot/home/groups/kernel/htdocs/debian

The contents of each dist is maintained in a 'pkglist' file.
(sarge/updates is the only dist at the moment).  pkglist files just
contain a list of .changes files to include.  A toplevel Makefile
processes these files, creates the dists/ hierarchy, and finally runs
apt-ftparchive generate.

This should make it easy to quickly add dists and share packages between
them.  Say, sarge-proposed-updates or sarge-backports.  (Not that we
shouldn't use backports.org or volatile where appropriate, of course).
We could store these pkglists in svn at some point, should we want
revision control on the archive.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ata_piix sata support - patch for 2.4.27

[dann frazier]

On Thu, 2005-10-06 at 17:26 -0400, Larry Lindsey wrote:
> I've produced a patch against the Debian 2.4.27 sources, which adds
> ata_piix support (ICH6, ICH7).  A lot of Dell machines use this
> chipset.  Its pretty klugey, but I hope its useful.
> 
> http://www.math.gatech.edu/~lindsey/libata-piix-2.4.27.patch.tar.bz2
> http://www.math.gatech.edu/~lindsey/libata-piix-2.4.27.patch.deb
> 

Thanks Larry.

Your best bet for getting your changes into the Debian kernel is get
these patches accepted in the upstream 2.4 tree; we can then attempt to
backport it to the 2.4.27 tree (assuming we're still maintaining one).
I don't know how open they are for new features though.

Any reason you can't use a 2.6 kernel?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ata_piix sata support - patch for 2.4.27

[Larry Lindsey]

I've produced a patch against the Debian 2.4.27 sources, which adds
ata_piix support (ICH6, ICH7).  A lot of Dell machines use this
chipset.  Its pretty klugey, but I hope its useful.

http://www.math.gatech.edu/~lindsey/libata-piix-2.4.27.patch.tar.bz2
http://www.math.gatech.edu/~lindsey/libata-piix-2.4.27.patch.deb

-Larry

Re: initrd-tools and booting root on lvm with new kernel

[Maximilian Attems]

On Thu, Oct 06, 2005 at 08:24:49PM +0200, Jonas Smedegaard wrote:
> Maximilian Attems <[EMAIL PROTECTED]> wrote:

> > also it would be _very_ cool to do the switch after a major upload.
> > just the switch to the newer tools and nothing else.
> > ubuntu has been bitten by this transition.
> > the user won't recognise that the oops is not the kernel fault.
> > the best plan would be to do it after an 2.6.13-1 upload:
> > an 2.6.13-2 with only this change.
> 
> If I understand you correctly then that only helps users frewuently
> bringing their system up-to-date, and not someone doing a dist-upgrade
> a year from now...

the linux-images get _lots_ of bug reports if something fails,
and history tells that user confuse easily initrd-tools and kernel bugs.
they won't notice that their oops is not a kernel trouble,
but eventual broken early userland.
it's about ironing out the changes and having an easy short term fall back.

--
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.12 crash when using bluetooth

[Uplink]

I did a quick test with the real Debian kernel from unstable and it 
doesn't crash. Seems that pre-emption has something to do with my issue. 
Looks like building from source has some other defaults than the Debian 
kernel. I now know to explicitely load the config file before 
compiling... Thanks.


Jurij Smakov wrote:


Hello,

Unable to handle kernel NULL pointer dereference at virtual address 
0008

printing eip:
c0244a15
*pde = 
Oops:  [#1]
PREEMPT



I believe that CONFIG_PREEMPT is disabled in packaged Debian kernels, 
yet the oops information you provide indicates that it is enabled. Can 
you try reproducing the problem with a kernel which does not have 
CONFIG_PREEMPT set?





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd-tools and booting root on lvm with new kernel

[Sven Luther]

On Thu, Oct 06, 2005 at 08:24:49PM +0200, Jonas Smedegaard wrote:
> > > I guess we could add a version specific check into the
> > >  postinst to default to using yaird or mkinitramfs , if installed,
> > > in preference to mkinitrd, though I am usually hesitant to add in
> > >  version dependencies into kernel-package in general, I could be
> > >  persuaded that an exception is justified in this case.
> 
> Alternatively kernel-package could fallback to other (installed) tools
> if the default one fails, instead of hardcoding version numbers. Still
> the priority of tools looked for and attempted would make sense to
> adapt to the kernel version, but would then be less intrusivese.
> 
> mkinitrd could then have hardcoded that 2.6.13 and newer Will Fail(tm).

That is a neat idea, have all three initrd tools know what version they
support and not, and do the check. Or even have a :

  --supported-version 

option which could be queried to check if this version is ok, then we need
only to be able to set the ordering of the different tools like :

mkimage_order = mkinitrd.yaird mkinitramfs mkinitrd

for example, and kernel-package would query those executable (if present) to
know if they support the kernel version which is tried to be installed, and
then try the one with higher priority. 

> yaird by design is quite knowledgable at build time about the chances of
> an image being broken (because it probes hardware at build time, where
> mkinitramfs probes at runtime) and will fail if something is wrong.

How does it react when running a 2.2 or 2.4 kernel and upgrading to a 2.6
kernel though ?

> Don't know avbout mkinitramfs but at least situations like "needs 2.6.12
> or newer" could be hardcoded if it would otherwise silently build a
> broken image.

Indeed.

> > there are archs which should prefer mkinitrd at current state of
> > affairs.
> > 
> > also it would be _very_ cool to do the switch after a major upload.
> > just the switch to the newer tools and nothing else.
> > ubuntu has been bitten by this transition.
> > the user won't recognise that the oops is not the kernel fault.
> > the best plan would be to do it after an 2.6.13-1 upload:
> > an 2.6.13-2 with only this change.
> 
> If I understand you correctly then that only helps users frewuently
> bringing their system up-to-date, and not someone doing a dist-upgrade
> a year from now...

Well, it helps the developers in helping make atomic changes to the package,
so we know it breaks because of 2.6.13 weirdness or because of the initrd
creation changes :)

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd-tools and booting root on lvm with new kernel

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 6 Oct 2005 17:44:02 +0200
Maximilian Attems <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 06, 2005 at 09:29:06AM -0500, Manoj Srivastava wrote:
> 
[snip snip]
> > mkinitramfs fails if the kernel
> > version is not at least 2.6.12, so it can't be used unilaterally. 

yaird should work with 2.6.8 and newer.

Added info to wiki page.


> > I guess we could add a version specific check into the
> >  postinst to default to using yaird or mkinitramfs , if installed,
> > in preference to mkinitrd, though I am usually hesitant to add in
> >  version dependencies into kernel-package in general, I could be
> >  persuaded that an exception is justified in this case.

Alternatively kernel-package could fallback to other (installed) tools
if the default one fails, instead of hardcoding version numbers. Still
the priority of tools looked for and attempted would make sense to
adapt to the kernel version, but would then be less intrusivese.

mkinitrd could then have hardcoded that 2.6.13 and newer Will Fail(tm).

yaird by design is quite knowledgable at build time about the chances of
an image being broken (because it probes hardware at build time, where
mkinitramfs probes at runtime) and will fail if something is wrong.

Don't know avbout mkinitramfs but at least situations like "needs 2.6.12
or newer" could be hardcoded if it would otherwise silently build a
broken image.


> there are archs which should prefer mkinitrd at current state of
> affairs.
> 
> also it would be _very_ cool to do the switch after a major upload.
> just the switch to the newer tools and nothing else.
> ubuntu has been bitten by this transition.
> the user won't recognise that the oops is not the kernel fault.
> the best plan would be to do it after an 2.6.13-1 upload:
> an 2.6.13-2 with only this change.

If I understand you correctly then that only helps users frewuently
bringing their system up-to-date, and not someone doing a dist-upgrade
a year from now...


 - Jonas

- - -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
- -BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDRWjbn7DbMsAkQLgRAkuKAJwOYHigfRRVdnI+YDaTLPBpFfms8ACdEc94
c84diJrVbWKFN7xP6G/+f/M=
=iPMY
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDRWvxn7DbMsAkQLgRAgYBAJ9YQtg4yKAf4IGKB542zd8hN1b40ACgk7uc
EmvNve1dBp2GfVLXZ7zccpY=
=IV0V
-END PGP SIGNATURE-

Re: initrd-tools and booting root on lvm with new kernel

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 6 Oct 2005 17:57:08 +0200
Sven Luther <[EMAIL PROTECTED]> wrote:

> mkyaird (or whatever it is called)

mkinitrd.yaird is the name of the yaird wrapper with mkinitrd options.


 - Jonas


- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDRWmIn7DbMsAkQLgRAutHAJ44n8SMm0mmWgCCVqteRaWLQ4YSZQCfVuiV
MTtUYezDTqss28NjHn+ktIE=
=ICse
-END PGP SIGNATURE-

Re: initrd-tools and booting root on lvm with new kernel

[Sven Luther]

On Thu, Oct 06, 2005 at 07:31:18PM +0200, Maximilian Attems wrote:
> On Thu, Oct 06, 2005 at 06:58:55PM +0200, Sven Luther wrote:
>  
> > Do you have a link to it ? And does it support using yaird as alternative ? 
> > Or
> > running initrd 2.4 or pre-2.6.12 kernels ?
> 
> it's supporting initrd-tools on hppa and ia64 afaik.
>  
> > The above proposal works with kernel-package just fine.
> 
> ok so i misunderstood you.
>  
> > > my proposal is just to localize changes, so that we clearly know,
> > > what broke?
> > > 
> > > releasing a new upstream version and changing the early boot stuff
> > > in the same time needs to be avoided.
> > 
> > I don't follow you on this.
> 
> the idea is to to have early boot change without any other bunch of
> usual fixes and changes. they would be noise for that transition.

I higlhly oppose doing a 2.6.13-2 upload just for that, it would be a giant
waste of auto-builder time.


Oh well, i guess it will be no worse than previous failed upload attempts ...

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd-tools and booting root on lvm with new kernel

[Maximilian Attems]

On Thu, Oct 06, 2005 at 06:58:55PM +0200, Sven Luther wrote:
 
> Do you have a link to it ? And does it support using yaird as alternative ? Or
> running initrd 2.4 or pre-2.6.12 kernels ?

it's supporting initrd-tools on hppa and ia64 afaik.
 
> The above proposal works with kernel-package just fine.

ok so i misunderstood you.
 
> > my proposal is just to localize changes, so that we clearly know,
> > what broke?
> > 
> > releasing a new upstream version and changing the early boot stuff
> > in the same time needs to be avoided.
> 
> I don't follow you on this.

the idea is to to have early boot change without any other bunch of
usual fixes and changes. they would be noise for that transition.

--
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Sven Luther]

On Thu, Oct 06, 2005 at 11:57:16AM -0500, Manoj Srivastava wrote:
> On Thu, 6 Oct 2005 18:07:24 +0200, Sven Luther <[EMAIL PROTECTED]> said: 
> 
> >> So, if there is an explicit value, use that, or else fall back
> >> through any of mkinitrd, mkinitramfs, or yaird, which happen to be
> >> installed.
> 
> > What about delegating the initrd creation to the
> > /etc/kernel/postinst.d script, and have make-kpkg include such a
> > versioned post-inst script into the kernel image ?
> 
> Sure. I guess that would be indistinguishable from the
>  kernel-package (and the kernel-image) viewpoint functionally, and
>  would allow one to recreate the initial root disk at will, so it is
>  better for the end user.

:)

> > or alternatively have initramfs or yaird provide those scripts in
> > /etc/kernel/postinst.d/, and do the right thing, and kill the stuff
> > doing this through /etc/kernel-img.conf for etch ?
> 
> Well, there is the issue of backwards compatibility: if there
>  are users who have set up the /etc/kernel-img.conf, one should not
>  suddenly have things fail for them.

Indeed, there should be some (to be determined) solution for those situations.

> I have no objection to transitioning to moving the initrd
>  creation out of the monolithic postinst script, and into
>  /etc/postinst.d (note: we'll have to also add stuff to the postrm to
>  remove these scripts on purge); as long as the transition is smooth
>  for the installed base.
>
> The script, if provided by kernel-package, would also need to
>  parse the kernel image configurations, if we are going to allow the
>  user to still specify their preference (yaird vs mkinitramfs vs
>  mkinitrd vs something else entirely).

Yes, altough just parsing kernel-img.conf is not enough, since we need to have
per-version choices of those. using /etc/kernel/config/ would be one
possibility, put doesn't adapt well to more flexible things like :

  1) different stuff for 2.4 and 2.6 kernels.

  2) different stuff for kernels > 2.6.12.

maybe some format allowing to add versioned constraints to the main config
file ? Not sure how clean that would be, imagine :

mkimage = mkinitrd
mkimage [$version > 2.6.12] = yaird

Or something thus ? 

> > Maybe we could even compliment the scripts in /etc/kernel with a
> > per-version configuration file to replace the main one ? the
> > make-kpkg provided scripts would parse /etc/kernel/config/kernel.cfg
> > and /etc/kernel/config//kernel.cfg ?
> 
> That is also a doable idea, but of somehwat limited utility
>  for the ordinary user (I usually only install a kerel image of a
>  particular version only once, so per version configuration files are
>  somethings I would never actually get around to setting up).

Well, see above.

> I also see no reason to move /etc/kernel-img.conf to
>  /etc/kernel/config/kernel.cfg (a lot of churn, and a transition to
>  support the old and the new, with little added utility); but I can
>  additionally also look at /etc/kernel/config//kernel.cfg,
>  since that would not impact current users.

maybe simply : /etc/kernel/config/ ? 

> >> I guess we could add a version specific check into the postinst to
> >> default to using yaird or mkinitramfs , if installed, in preference
> >> to mkinitrd, though I am usually hesitant to add in version
> >> dependencies into kernel-package in general, I could be persuaded
> >> that an exception is justified in this case.
> 
> > there are archs which should prefer mkinitrd at current state of
> > affairs.
> 
> Hmm. I would much rather not have to learn and main per-arch
>  idiosyncrasies for kernel-package

Indeed, which is why i advocate moving that info into the kernel rules. Or
even in a per-arch kernel-knowledge-base package.

> > also it would be _very_ cool to do the switch after a major upload.
> > just the switch to the newer tools and nothing else.  ubuntu has
> > been bitten by this transition.  the user won't recognise that the
> > oops is not the kernel fault.  the best plan would be to do it after
> > an 2.6.13-1 upload: an 2.6.13-2 with only this change.
> 
> Well, if we can comeup with a reasonably robust mechanism for
>  determining what sequence the initrd creation tools should be tried
>  in, given a kernel version and an architecture, and something that
>  does not need to be maintained (people have had reasonably good
>  experience using kernel-package for creating kernel images for
>  versions very different from the noes current when that version of
>  kernel-package was written, barring bugs in kernel-package -o I would
>  not want to lose that version agnostic behaviour by design)

Indeed, but i guess you can keep it with using some modular schema like
discussed above, which would default to the standard case and allow us to add
more advanced solution for newer official kernels and such.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "u

Re: initrd-tools and booting root on lvm with new kernel

[Sven Luther]

On Thu, Oct 06, 2005 at 06:43:54PM +0200, Maximilian Attems wrote:
> On Thu, Oct 06, 2005 at 05:57:08PM +0200, Sven Luther wrote:
> > On Thu, Oct 06, 2005 at 09:29:06AM -0500, Manoj Srivastava wrote:
> > > On Mon, 3 Oct 2005 13:03:45 +0200, Maximilian Attems
> > > <[EMAIL PROTECTED]> said:  
> > > 
> > > > naa initramfs-tools are in the archive an working for all arch but
> > > > sparc (klibc ftbfs there with gcc3.4/4.0).
> > > 
> > > > the kernel-package does not yet use the initramfs-tools. you need to
> > > > invoke update-initramfs like this: sudo update-initramfs -c -k
> > > > 2.6.13-1-686
> > > 
> > > Err. putting 
> > >   ramdisk = /usr/sbin/mkinitramfs
> > >  in /etc/kernel-img.conf does seem to work. Or are you talking about
> > >  using mkinitramfs by default? mkinitramfs fails if the kernel version
> > >  is not at least 2.6.12, so it can't be used unilaterally. 
> > 
> > Would a solution to this not to have the kernel provide a
> > /etc/kernel/postinst.d//kernel.sh script, which would in turn call
> > mkinitramfs or mkyaird (or whatever it is called), or alternatively have
> ..
> the patch that uses mkinitramfs-tools conditionaly in ubuntu is very
> small and easy to integrate.

Do you have a link to it ? And does it support using yaird as alternative ? Or
running initrd 2.4 or pre-2.6.12 kernels ?

> > > I guess we could add a version specific check into the
> > >  postinst to default to using yaird or mkinitramfs , if installed, in
> > >  preference to mkinitrd, though I am usually hesitant to add in
> > >  version dependencies into kernel-package in general, I could be
> > >  persuaded that an exception is justified in this case.
> > 
> > Would a solution as proposed above be more to your liking :) ?
> 
> naa, working with kernel-package is very fine.

The above proposal works with kernel-package just fine.

> my proposal is just to localize changes, so that we clearly know,
> what broke?
> 
> releasing a new upstream version and changing the early boot stuff
> in the same time needs to be avoided.

I don't follow you on this.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Manoj Srivastava]

On Thu, 6 Oct 2005 18:07:24 +0200, Sven Luther <[EMAIL PROTECTED]> said: 

>> So, if there is an explicit value, use that, or else fall back
>> through any of mkinitrd, mkinitramfs, or yaird, which happen to be
>> installed.

> What about delegating the initrd creation to the
> /etc/kernel/postinst.d script, and have make-kpkg include such a
> versioned post-inst script into the kernel image ?

Sure. I guess that would be indistinguishable from the
 kernel-package (and the kernel-image) viewpoint functionally, and
 would allow one to recreate the initial root disk at will, so it is
 better for the end user.

> or alternatively have initramfs or yaird provide those scripts in
> /etc/kernel/postinst.d/, and do the right thing, and kill the stuff
> doing this through /etc/kernel-img.conf for etch ?

Well, there is the issue of backwards compatibility: if there
 are users who have set up the /etc/kernel-img.conf, one should not
 suddenly have things fail for them.

I have no objection to transitioning to moving the initrd
 creation out of the monolithic postinst script, and into
 /etc/postinst.d (note: we'll have to also add stuff to the postrm to
 remove these scripts on purge); as long as the transition is smooth
 for the installed base.

The script, if provided by kernel-package, would also need to
 parse the kernel image configurations, if we are going to allow the
 user to still specify their preference (yaird vs mkinitramfs vs
 mkinitrd vs something else entirely).

> Maybe we could even compliment the scripts in /etc/kernel with a
> per-version configuration file to replace the main one ? the
> make-kpkg provided scripts would parse /etc/kernel/config/kernel.cfg
> and /etc/kernel/config//kernel.cfg ?

That is also a doable idea, but of somehwat limited utility
 for the ordinary user (I usually only install a kerel image of a
 particular version only once, so per version configuration files are
 somethings I would never actually get around to setting up).

I also see no reason to move /etc/kernel-img.conf to
 /etc/kernel/config/kernel.cfg (a lot of churn, and a transition to
 support the old and the new, with little added utility); but I can
 additionally also look at /etc/kernel/config//kernel.cfg,
 since that would not impact current users.

>> I guess we could add a version specific check into the postinst to
>> default to using yaird or mkinitramfs , if installed, in preference
>> to mkinitrd, though I am usually hesitant to add in version
>> dependencies into kernel-package in general, I could be persuaded
>> that an exception is justified in this case.

> there are archs which should prefer mkinitrd at current state of
> affairs.

Hmm. I would much rather not have to learn and main per-arch
 idiosyncrasies for kernel-package

> also it would be _very_ cool to do the switch after a major upload.
> just the switch to the newer tools and nothing else.  ubuntu has
> been bitten by this transition.  the user won't recognise that the
> oops is not the kernel fault.  the best plan would be to do it after
> an 2.6.13-1 upload: an 2.6.13-2 with only this change.

Well, if we can comeup with a reasonably robust mechanism for
 determining what sequence the initrd creation tools should be tried
 in, given a kernel version and an architecture, and something that
 does not need to be maintained (people have had reasonably good
 experience using kernel-package for creating kernel images for
 versions very different from the noes current when that version of
 kernel-package was written, barring bugs in kernel-package -o I would
 not want to lose that version agnostic behaviour by design)

manoj
-- 
To program anything that is programmable is obsession.
Manoj Srivastava <[EMAIL PROTECTED]>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd-tools and booting root on lvm with new kernel

[Maximilian Attems]

On Thu, Oct 06, 2005 at 05:57:08PM +0200, Sven Luther wrote:
> On Thu, Oct 06, 2005 at 09:29:06AM -0500, Manoj Srivastava wrote:
> > On Mon, 3 Oct 2005 13:03:45 +0200, Maximilian Attems
> > <[EMAIL PROTECTED]> said:  
> > 
> > > naa initramfs-tools are in the archive an working for all arch but
> > > sparc (klibc ftbfs there with gcc3.4/4.0).
> > 
> > > the kernel-package does not yet use the initramfs-tools. you need to
> > > invoke update-initramfs like this: sudo update-initramfs -c -k
> > > 2.6.13-1-686
> > 
> > Err. putting 
> >   ramdisk = /usr/sbin/mkinitramfs
> >  in /etc/kernel-img.conf does seem to work. Or are you talking about
> >  using mkinitramfs by default? mkinitramfs fails if the kernel version
> >  is not at least 2.6.12, so it can't be used unilaterally. 
> 
> Would a solution to this not to have the kernel provide a
> /etc/kernel/postinst.d//kernel.sh script, which would in turn call
> mkinitramfs or mkyaird (or whatever it is called), or alternatively have
..
the patch that uses mkinitramfs-tools conditionaly in ubuntu is very
small and easy to integrate.

> > I guess we could add a version specific check into the
> >  postinst to default to using yaird or mkinitramfs , if installed, in
> >  preference to mkinitrd, though I am usually hesitant to add in
> >  version dependencies into kernel-package in general, I could be
> >  persuaded that an exception is justified in this case.
> 
> Would a solution as proposed above be more to your liking :) ?

naa, working with kernel-package is very fine.
my proposal is just to localize changes, so that we clearly know,
what broke?

releasing a new upstream version and changing the early boot stuff
in the same time needs to be avoided.

--
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Secure-testing-team] 2.6.13.{123}

[Moritz Muehlenhoff]

Horms wrote:
> > > It also seems to me that none of the patches in 2.6.13.3 are security
> > > related, I'd apprciate someone casting an eye over that.
> > 
> > It's not obvious from the code, but the description for 
> > 
> > | Stephen Hemminger:
> > |  skge: set mac address oops with bonding
> > 
> > seems to indicate that a user can trigger an oops by setting a MAC
> > address with ifconfig?
> 
> I'll take a look, but isn't that a privelaged oppertion anyway?

Doh, you're right, of course.

Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A new round of kernel vulnerabilities

[Horms]

On Thu, Oct 06, 2005 at 03:16:26PM +0200, Moritz Muehlenhoff wrote:
> Hi,
> as usual; to minimize the overhead I'm sending these again by email and not
> through the BTS.

thanks, I've put that in my new holding pen,
kernel/people/horms/patch_note on svn.debian.org as
newcve-2005-10-06

I'm not sure if putting stuff there is actually going to 
be useful to me or anyone else. But I guess we are going
to find out :)

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Secure-testing-team] 2.6.13.{123}

[Horms]

On Thu, Oct 06, 2005 at 03:39:22PM +0200, Moritz Muehlenhoff wrote:
> Horms wrote:
> > The next things I will be looking at are:
> >   Checking off CAN Numbers
> > 
> > I have put my notes in SVN - there is nothing private there.
> > These include notes on each of 2.6.13.{123} and a list
> > of recently released CAN numbers. I think some of the 
> > CAN numbers correlate to 2.6.13.{123} patches which don't
> > have CANs, but I have not checked.
> 
> I can do so on sunday, if anybody has free time before, please go ahead.

Thanks, I will try and do it tomorrow, but if I don't then
I almost certainly won't get to it until Tuesday or Wednesday.

> > It also seems to me that none of the patches in 2.6.13.3 are security
> > related, I'd apprciate someone casting an eye over that.
> 
> It's not obvious from the code, but the description for 
> 
> | Stephen Hemminger:
> |  skge: set mac address oops with bonding
> 
> seems to indicate that a user can trigger an oops by setting a MAC
> address with ifconfig?

I'll take a look, but isn't that a privelaged oppertion anyway?

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Horms]

On Thu, Oct 06, 2005 at 02:20:53PM +0200, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Thu, 6 Oct 2005 12:30:28 +0100
> Colin Watson <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, Oct 06, 2005 at 01:09:59PM +0200, Sven Luther wrote:
> > > On Thu, Oct 06, 2005 at 06:45:13PM +0900, Horms wrote:
> > > > I am, right at this moment, building 2.6.13-1.experimental.1, and
> > > 
> > > This should be 2.6.13-0.experimental.1, which would be lower than
> > > 2.6.13-1 which we would upload to unstable. Don't forget to make
> > > sure you include the .orig tarball though, as i don't think it is
> > > included in 0.experimental.1 by default.
> > 
> > That ought to be 2.6.13-0experimental1, otherwise various bits of the
> > archive maintenance software will treat it as a binary-only NMU in
> > some ways and get confused. I've made that mistake before ...
> 
> Oh, didn't know that. Is it (pseudo)documented anywhere?
> 
> I think I experienced once that a 0alphanum1 would not get upgraded
> automatically to a 0alphanum2 package. But if this is the proper way
> then I must've been dreaming.

For the record, Sven and I decided to go with 2.6.13-1, to avoid
confusion and some internal packaging complications.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Sven Luther]

On Thu, Oct 06, 2005 at 09:21:11AM -0500, Manoj Srivastava wrote:
> On Wed, 5 Oct 2005 18:25:40 +0200, Sven Luther <[EMAIL PROTECTED]> said: 
> 
> > On Wed, Oct 05, 2005 at 12:12:10PM -0400, Joey Hess wrote:
> >> d-i contains code to install and set up initrd-tools. The
> >> likelyhood of yaird or initramfs-tools working everywhere with no
> >> d-i changes is zero.
> 
> > Ah, ...
> 
> > Well, ideally i believe it would be the responsability of the kernel
> > package to set that up, but this is probably not going to happen
> > until we get ride of kernel-package or rewrite it to some extent.
> 
> Way to go about setting up cooperative changes. Why am I not
>  surprised?

Bah, sorry for the maybe too agressive wording, it wasn't meant so, and see my
other message about this.

> The only reason we have images that are marked "initrd" is
>  the possibility that the kernel may not have the driver for the root
>  file system compiled in, and would need an initial root file system
>  somehow. If the various options -- creating  initrd or initramfs --
>  can be selected by each user on the target machine at install time,
>  and would all work equally well, one can just try each of the init
>  image creation tools in succession.

Well, see below. ...

> As far as I can see, there is no special config option
>  required to distinguish between initrd and initramfs, so that is not
>  a concern.

... you are (i believe) facing a common miscomprehension. There are two issues
at hand here :

  1) the actual initrd format (either ext2 as used in 2.4 kernels in the
  paste, cramfs or initramfs).

  2) the program used to fill said initrd with actual content.

initrd-tool can do either ext2 or cramfs, but not really initramfs, altough i
believe you can override it with the right invocation to cpio used with the
right option of initrd-tools. it defaults to ext2 on 2.4 kernels and cramfs on
2.6 ones, i believe.

initramfs-tools and yaird default to initramfs format, but could probably
generate cramfs or ext2 just as well.

The content creation is different both in implementation and in philosophy,
initramfs-tools and initrd-tools share the same implementation based on a
shell script (mkinitrd), and the philosophy of trying to put as much as
possible in the initrd, in hopes to survive hardware modifications. Yaird on
the other hand uses some perl scripts (i believe), with some external config
files, and as the philosophy of putting only the strict minimum into the
initrd.

One could add a fourth initrd creation tool into the mix, namely
debian-installer, which with a few modifications, could easily enough be made
to pivot_root into the real system post hardware detection.

> I have not seen any differences in the naming conventions of
>  the init images produced, so the naming of the destination of the
>  init image is not an issue either.

Indeed.

> > Now, i installed yaird, and the only modification i had to do to my
> > /etc/kernel-img.conf was to set the mkinitrd-hook, or whatever this
> > one was called to point to yaird instead of mkinitrd, and it worked
> > out of the box, and since a solution using this would use an
> > automatically replacement solution, i think there should be no major
> > problem for yaird at least, not sure about initramfs-tools though.
> 
> Jonas> This seems to be the same for initramfs-tools:
> Jonas>   ramdisk = /usr/sbin/mkinitramfs
> Jonas> I have not tested how that works with LVM and mdadm.
> 
> So, if there is an explicit value, use that, or else fall back
>  through any of mkinitrd, mkinitramfs, or yaird, which happen to be
>  installed.

What about delegating the initrd creation to the /etc/kernel/postinst.d
script, and have make-kpkg include such a versioned post-inst script into the
kernel image ?

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd-tools and booting root on lvm with new kernel

[Maximilian Attems]

On Thu, Oct 06, 2005 at 09:29:06AM -0500, Manoj Srivastava wrote:

> Err. putting 
>   ramdisk = /usr/sbin/mkinitramfs
>  in /etc/kernel-img.conf does seem to work. 

indeed, thanks for pointing that out.

>  Or are you talking about
>  using mkinitramfs by default? mkinitramfs fails if the kernel version
>  is not at least 2.6.12, so it can't be used unilaterally. 
> 
> I guess we could add a version specific check into the
>  postinst to default to using yaird or mkinitramfs , if installed, in
>  preference to mkinitrd, though I am usually hesitant to add in
>  version dependencies into kernel-package in general, I could be
>  persuaded that an exception is justified in this case.
 
there are archs which should prefer mkinitrd at current state of
affairs.

also it would be _very_ cool to do the switch after a major upload.
just the switch to the newer tools and nothing else.
ubuntu has been bitten by this transition.
the user won't recognise that the oops is not the kernel fault.
the best plan would be to do it after an 2.6.13-1 upload:
an 2.6.13-2 with only this change.

--
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd-tools and booting root on lvm with new kernel

[Sven Luther]

On Thu, Oct 06, 2005 at 09:29:06AM -0500, Manoj Srivastava wrote:
> On Mon, 3 Oct 2005 13:03:45 +0200, Maximilian Attems
> <[EMAIL PROTECTED]> said:  
> 
> > naa initramfs-tools are in the archive an working for all arch but
> > sparc (klibc ftbfs there with gcc3.4/4.0).
> 
> > the kernel-package does not yet use the initramfs-tools. you need to
> > invoke update-initramfs like this: sudo update-initramfs -c -k
> > 2.6.13-1-686
> 
> Err. putting 
>   ramdisk = /usr/sbin/mkinitramfs
>  in /etc/kernel-img.conf does seem to work. Or are you talking about
>  using mkinitramfs by default? mkinitramfs fails if the kernel version
>  is not at least 2.6.12, so it can't be used unilaterally. 

Would a solution to this not to have the kernel provide a
/etc/kernel/postinst.d//kernel.sh script, which would in turn call
mkinitramfs or mkyaird (or whatever it is called), or alternatively have
initramfs or yaird provide those scripts in /etc/kernel/postinst.d/, and do
the right thing, and kill the stuff doing this through /etc/kernel-img.conf
for etch ? Maybe we could even compliment the scripts in /etc/kernel with a
per-version configuration file to replace the main one ? the make-kpkg
provided scripts would parse /etc/kernel/config/kernel.cfg and
/etc/kernel/config//kernel.cfg ?

> I guess we could add a version specific check into the
>  postinst to default to using yaird or mkinitramfs , if installed, in
>  preference to mkinitrd, though I am usually hesitant to add in
>  version dependencies into kernel-package in general, I could be
>  persuaded that an exception is justified in this case.

Would a solution as proposed above be more to your liking :) ?

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Secure-testing-team] A new round of kernel vulnerabilities

[micah]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


These are the CVE assignments I requested from Mitre for the security
patches that have been already applied to the 2.6.8sarge1 update.
I will work with horms to get these added to the changelog entries
next to the patches which address the problems.

Micah


Moritz Muehlenhoff wrote:

> Hi, as usual; to minimize the overhead I'm sending these again by
> email and not through the BTS.
>
> CAN-2005-3110: DoS on SMP, potentially 2.4 and 2.6
> http://sourceforge.net/mailarchive/forum.php?thread_id=6800453&forum_id=8572
>
>
> CAN-2005-3109: Local DoS through oops by mounting a non-HFS+
> filesystem as HFS+.
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=945b092011c6af71a0107be96e119c8c08776f3f
>
>
> CAN-2005-3108: DoS and potential information leak in ioremap
> (seemingly specific to amd64)
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=93ef70a217637ade3f335303a112b22a134a1ec2
>
>
> CAN-2005-3107: Local DoS through threads tracing each other by
> forcing a core dump, while the traced thread is in TASK_TRACED
> state.
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/broken-out/fix-coredump_wait-deadlock-with-ptracer-tracee-on-shared-mm.patch
>
>
> CAN-2005-3106: DoS through race condition in processes that share a
> memory mapping through CLONE_VM
> http://linux.bkbits.net:8080/linux-2.6/diffs/fs/[EMAIL 
> PROTECTED]|src/|src/fs|hist/fs/exec.c
>
>
> CAN-2005-3105: ia64 Montecito CPU do not maintain cache coherency
> correctly, which can be exploited by a local DoS.
> http://linux.bkbits.net:8080/linux-2.6/[EMAIL 
> PROTECTED]|src/|src/mm|related/mm/mprotect.c
>
>
> Cheers, Moritz
>
> ___ Secure-testing-team
> mailing list Secure-testing-team@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDRTQT9n4qXRzy1ioRAoKRAJsGUSRaKIlxe6VVzEJquG7WktwGhgCglpe9
f6eFq6/pL8jWckbN5BIcyVY=
=2dBi
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: initrd-tools and booting root on lvm with new kernel

[Manoj Srivastava]

On Mon, 3 Oct 2005 13:03:45 +0200, Maximilian Attems
<[EMAIL PROTECTED]> said:  

> naa initramfs-tools are in the archive an working for all arch but
> sparc (klibc ftbfs there with gcc3.4/4.0).

> the kernel-package does not yet use the initramfs-tools. you need to
> invoke update-initramfs like this: sudo update-initramfs -c -k
> 2.6.13-1-686

Err. putting 
  ramdisk = /usr/sbin/mkinitramfs
 in /etc/kernel-img.conf does seem to work. Or are you talking about
 using mkinitramfs by default? mkinitramfs fails if the kernel version
 is not at least 2.6.12, so it can't be used unilaterally. 

I guess we could add a version specific check into the
 postinst to default to using yaird or mkinitramfs , if installed, in
 preference to mkinitrd, though I am usually hesitant to add in
 version dependencies into kernel-package in general, I could be
 persuaded that an exception is justified in this case.

manoj
-- 
Dare to be naive. Buckminster Fuller
Manoj Srivastava <[EMAIL PROTECTED]>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Manoj Srivastava]

On Wed, 5 Oct 2005 18:25:40 +0200, Sven Luther <[EMAIL PROTECTED]> said: 

> On Wed, Oct 05, 2005 at 12:12:10PM -0400, Joey Hess wrote:
>> d-i contains code to install and set up initrd-tools. The
>> likelyhood of yaird or initramfs-tools working everywhere with no
>> d-i changes is zero.

> Ah, ...

> Well, ideally i believe it would be the responsability of the kernel
> package to set that up, but this is probably not going to happen
> until we get ride of kernel-package or rewrite it to some extent.

Way to go about setting up cooperative changes. Why am I not
 surprised?

The only reason we have images that are marked "initrd" is
 the possibility that the kernel may not have the driver for the root
 file system compiled in, and would need an initial root file system
 somehow. If the various options -- creating  initrd or initramfs --
 can be selected by each user on the target machine at install time,
 and would all work equally well, one can just try each of the init
 image creation tools in succession.

As far as I can see, there is no special config option
 required to distinguish between initrd and initramfs, so that is not
 a concern.

I have not seen any differences in the naming conventions of
 the init images produced, so the naming of the destination of the
 init image is not an issue either.

> Now, i installed yaird, and the only modification i had to do to my
> /etc/kernel-img.conf was to set the mkinitrd-hook, or whatever this
> one was called to point to yaird instead of mkinitrd, and it worked
> out of the box, and since a solution using this would use an
> automatically replacement solution, i think there should be no major
> problem for yaird at least, not sure about initramfs-tools though.

Jonas> This seems to be the same for initramfs-tools:
Jonas>   ramdisk = /usr/sbin/mkinitramfs
Jonas> I have not tested how that works with LVM and mdadm.

So, if there is an explicit value, use that, or else fall back
 through any of mkinitrd, mkinitramfs, or yaird, which happen to be
 installed.

manoj

-- 
Tact, n.: The unsaid part of what you're thinking.
Manoj Srivastava <[EMAIL PROTECTED]>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#317286: Processed: Re: Bug#317286: Please backport support for Promise SATAII TX2/TX4 cards (from 2.6.11)

[Chris Leigh]

Horms wrote:

  On Fri, Aug 19, 2005 at 08:46:29AM -0500, Chris Leigh wrote:
  
  
I have tried the patched kernel, and although it was able to compile,
it did not work correctly.

  
  
Sorry, its seems that I missed part of the patch, could 
you please try the revised version that is attached. 
Note that  the first chunk is the original patch that I sent,
and the second chunk is the but I missed.

  


This one compiles and works perfectly!  If you require the output from
dmesg or anything, please advise.
I'd consider this one 'resolved'.

Thank you very very much

Chris





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Secure-testing-team] 2.6.13.{123}

[Moritz Muehlenhoff]

Horms wrote:
> The next things I will be looking at are:
>   Checking off CAN Numbers
> 
> I have put my notes in SVN - there is nothing private there.
> These include notes on each of 2.6.13.{123} and a list
> of recently released CAN numbers. I think some of the 
> CAN numbers correlate to 2.6.13.{123} patches which don't
> have CANs, but I have not checked.

I can do so on sunday, if anybody has free time before, please go ahead.
 
> It also seems to me that none of the patches in 2.6.13.3 are security
> related, I'd apprciate someone casting an eye over that.

It's not obvious from the code, but the description for 

| Stephen Hemminger:
|  skge: set mac address oops with bonding

seems to indicate that a user can trigger an oops by setting a MAC
address with ifconfig?

Cheers,
 Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

A new round of kernel vulnerabilities

[Moritz Muehlenhoff]

Hi,
as usual; to minimize the overhead I'm sending these again by email and not
through the BTS.

CAN-2005-3110:
DoS on SMP, potentially 2.4 and 2.6
http://sourceforge.net/mailarchive/forum.php?thread_id=6800453&forum_id=8572

CAN-2005-3109:
Local DoS through oops by mounting a non-HFS+ filesystem as HFS+.
http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=945b092011c6af71a0107be96e119c8c08776f3f

CAN-2005-3108:
DoS and potential information leak in ioremap (seemingly specific to amd64)
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=93ef70a217637ade3f335303a112b22a134a1ec2
 

CAN-2005-3107:
Local DoS through threads tracing each other by forcing a core dump, while the 
traced
thread is in TASK_TRACED state.
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/broken-out/fix-coredump_wait-deadlock-with-ptracer-tracee-on-shared-mm.patch

CAN-2005-3106:
DoS through race condition in processes that share a memory mapping through 
CLONE_VM
http://linux.bkbits.net:8080/linux-2.6/diffs/fs/[EMAIL 
PROTECTED]|src/|src/fs|hist/fs/exec.c

CAN-2005-3105:
ia64 Montecito CPU do not maintain cache coherency correctly, which can be 
exploited by
a local DoS.
http://linux.bkbits.net:8080/linux-2.6/[EMAIL 
PROTECTED]|src/|src/mm|related/mm/mprotect.c

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Problem synchronizing with IPAQ

[Ivan S. Dubrov]

Hello,

I'm trying to synchronize with my iPaq (rx3715) and get the following error (in 
dmesg):

usb 1-1: new full speed USB device using ohci_hcd and address 9
ipaq 1-1:2.0: PocketPC PDA converter detected
drivers/usb/serial/ipaq.c: active config #2 != 1 ??
ipaq: probe of 1-1:2.0 failed with error -5

How can I solve this problem?

I have kernel 2.6.12-1-amd64-k8 from the Etch distribution.

P.S. I've read sources a bit and found that the USB active configuration can be 
selected
by the hotplug, but it is not clear how (and if it can solve the problem).

WBR,
Ivan Dubrov.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 6 Oct 2005 12:30:28 +0100
Colin Watson <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 06, 2005 at 01:09:59PM +0200, Sven Luther wrote:
> > On Thu, Oct 06, 2005 at 06:45:13PM +0900, Horms wrote:
> > > I am, right at this moment, building 2.6.13-1.experimental.1, and
> > 
> > This should be 2.6.13-0.experimental.1, which would be lower than
> > 2.6.13-1 which we would upload to unstable. Don't forget to make
> > sure you include the .orig tarball though, as i don't think it is
> > included in 0.experimental.1 by default.
> 
> That ought to be 2.6.13-0experimental1, otherwise various bits of the
> archive maintenance software will treat it as a binary-only NMU in
> some ways and get confused. I've made that mistake before ...

Oh, didn't know that. Is it (pseudo)documented anywhere?

I think I experienced once that a 0alphanum1 would not get upgraded
automatically to a 0alphanum2 package. But if this is the proper way
then I must've been dreaming.


 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDRRaln7DbMsAkQLgRAiqvAKCUX1ru4UsRuXO35Wl9BWyXP3WS+wCfSFBH
6ORFqBP18np6OiYLHuBKyjQ=
=cz2g
-END PGP SIGNATURE-

Re: 2.6.13, experimental and 2.6.14-rc ...

[Colin Watson]

On Thu, Oct 06, 2005 at 01:09:59PM +0200, Sven Luther wrote:
> On Thu, Oct 06, 2005 at 06:45:13PM +0900, Horms wrote:
> > I am, right at this moment, building 2.6.13-1.experimental.1, and
> 
> This should be 2.6.13-0.experimental.1, which would be lower than 2.6.13-1
> which we would upload to unstable. Don't forget to make sure you include the
> .orig tarball though, as i don't think it is included in 0.experimental.1 by
> default.

That ought to be 2.6.13-0experimental1, otherwise various bits of the
archive maintenance software will treat it as a binary-only NMU in some
ways and get confused. I've made that mistake before ...

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Sven Luther]

On Thu, Oct 06, 2005 at 06:45:13PM +0900, Horms wrote:
> I am, right at this moment, building 2.6.13-1.experimental.1, and

This should be 2.6.13-0.experimental.1, which would be lower than 2.6.13-1
which we would upload to unstable. Don't forget to make sure you include the
.orig tarball though, as i don't think it is included in 0.experimental.1 by
default.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#100421: Re[3]: from Marina

[Marya]

Hello ! 

I'm a very young and energetic lady! I have very positive attitude to life and 
people. I do enjoy new experience life can offer me: to see new interesting 
places, to meet new people.
I do try to enjoy every moment of life and accept everything the way it comes 
without complaining.
Though my life seems to be quite enjoyable there's one important thing missing. 
It's LOVE!
Without my beloved one, my soul mate, my King my life is not completed.
I wish i coud find him very soon so that we could share together every momement 
of the life-time romance! 
What about you? Could you be my King? If answer is "yes" - you can find more 
about me 
http://YQ5m5re.withhopeforlove.com/

so long
Marya




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Horms]

On Thu, Oct 06, 2005 at 12:00:12PM +0200, Norbert Tretkowski wrote:
> * Horms wrote:
> > I am, right at this moment, building 2.6.13-1.experimental.1, and
> > assuming the i386 build completes I will upload. I already know it
> > doesn't compile on HPPA, and I expect other FTBFS.
> 
> It will fail on alpha too, I hope I'll find time next weekend to
> update the configs.

I was a bit frustrated about this whole FTBFS situation, and
I vented that a bit on IRC. But in the end Sven is right that
experimental is an appropriate palce for is to make uploads,
get autobuilds happening, and generally start getting the code out
there. I anticicapte we will end up releaing a few times a week
while its in experimental. Hopefully my ccache seeding plans
work out :)

Build is still going, I'm off home, will upload this evening
or tomorrow morning, assuming all goes well. I'm tagging the release
now. We can untag it as need be.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

2.6.13.{123}

[Horms]

Hi,

I have now gone through all of 2.6.13.{123} for 2.6.8 sarge 
and sarge-security. And these changes are all in SVN.

2.6.13.{123} are in trunk/ (2.6.13)

2.6.13.{12} are in sid/ (2.6.12)
I will add 2.6.13.3 if it looks like 2.6.12-11 is going to happen.

The next things I will be looking at are:
  2.6.13.{123} for 2.4.27 
  Checking off CAN Numbers

Assistance with either of these tasks would be greatly appreciated.

I have put my notes in SVN - there is nothing private there.
These include notes on each of 2.6.13.{123} and a list
of recently released CAN numbers. I think some of the 
CAN numbers correlate to 2.6.13.{123} patches which don't
have CANs, but I have not checked.

http://svn.debian.org/wsvn/kernel/people/horms/patch_notes/?rev=0&sc=0
svn co svn://svn.debian.org/kernel/people/horms/patch_notes/
svn+ssh://@svn.debian.org/kernel/people/horms/patch_notes

If you want to update them, please send me a patch or
commit straight into svn. Though I'd appreaciate an email to
let me know what you've done.


It also seems to me that none of the patches in 2.6.13.3 are security
related, I'd apprciate someone casting an eye over that.


-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Norbert Tretkowski]

* Horms wrote:
> I am, right at this moment, building 2.6.13-1.experimental.1, and
> assuming the i386 build completes I will upload. I already know it
> doesn't compile on HPPA, and I expect other FTBFS.

It will fail on alpha too, I hope I'll find time next weekend to
update the configs.

Norbert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#67718: Hey friend-I Had it done yesterday

[Millie Villa]

Hello, my name is Maria Freeman

I'd realy like to know:

Happy with your sexual performance?

We have another answer!

The generic advantage http://schlesinger.e.50.happinessischeap.com

good bye

Velma Orr



S..t..o..p : http://schlesinger.youthisgreatmeds.com/leavemealone.php   







-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332228: kernel-source-2.4.27: ipt_recent bug: stops working after a 250 days uptime

[Horms]

On Thu, Oct 06, 2005 at 10:10:34AM +0200, Ludovic Drolez wrote:
> On Thu, Oct 06, 2005 at 10:39:50AM +0900, Horms wrote:
> > I have talked with upstream, and Juergen Kreidleder who originally
> > discovered this bug about this problem. Unfortunately there is no patch
> > that fixes this problem that upstream is comfortable, so I would rather
> 
> But replacing jiffies with seconds seems to be nice...

I'm not convinced that it is a good solution.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#100421: Scrotum solutions

[Garrett Payne]

Hello, Hi mate, my name is Mindy Ledford

I'm curious:

Having troubles getting a full erection?

I recommend this Impotence levels solutions

Enetr our site http://chenille.e.50.happinessischeap.com

yours,

Mitzi Swanson



n..a..d..a : http://chenille.happinessischeap.com/nomore.php   






-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Horms]

On Thu, Oct 06, 2005 at 11:15:04AM +0200, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Thu, 6 Oct 2005 10:13:05 +0200
> Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Oct 05, 2005 at 08:19:14PM +0200, Jonas Smedegaard wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > > > If not, why?
> > > > 
> > > > I guess generic miscomprehension, or whatever. The fact that
> > > > ubuntu uses initramfs-tools for example, and so on.
> > > 
> > > I would guess similarly. My interest was (and still is) actual
> > > concrete reasons from those (if any) not interested.
> > > 
> > > Silence as response to both questions (from all but you and I) I
> > > dare interpret as "we have already decided on initramfs-tools and
> > > are either too lazy or too busy to even shed light on the issues we
> > > have with yaird".
> > 
> > Please interpret it as too busy to reply right now, as many in the
> > kernel team are over-worked with RL stuff these days :)
> 
> Ok - I apologize for being rude.
> 
> What does "RL" stand for?

I guess Real Life.

There has been a distinct lack of activity in the kernel-team over
the past week or so. I agree with Sven's analysis that this
implies people are busy. I for one am in that camp, though
I am doing kernel stuff today.

Unfortunately this isn't getting us much closer to resolving yaird vs
initramfs-tools or any other issues relating to 2.6.13 and beyond.

I am, right at this moment, building 2.6.13-1.experimental.1, and
assuming the i386 build completes I will upload. I already know it
doesn't compile on HPPA, and I expect other FTBFS. On the other hand, it
will probably work quite nicely on enough architectures that there is a
benifit to users. In any case, hopefully having some release out there
will get some more energy back into getting 2.6.13 and beyond into Etch.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 2.6.13, experimental and 2.6.14-rc ...

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 6 Oct 2005 10:13:05 +0200
Sven Luther <[EMAIL PROTECTED]> wrote:

> On Wed, Oct 05, 2005 at 08:19:14PM +0200, Jonas Smedegaard wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > > > If not, why?
> > > 
> > > I guess generic miscomprehension, or whatever. The fact that
> > > ubuntu uses initramfs-tools for example, and so on.
> > 
> > I would guess similarly. My interest was (and still is) actual
> > concrete reasons from those (if any) not interested.
> > 
> > Silence as response to both questions (from all but you and I) I
> > dare interpret as "we have already decided on initramfs-tools and
> > are either too lazy or too busy to even shed light on the issues we
> > have with yaird".
> 
> Please interpret it as too busy to reply right now, as many in the
> kernel team are over-worked with RL stuff these days :)

Ok - I apologize for being rude.

What does "RL" stand for?


> > > I think what would be of most interest is a technical description
> > > of both solutions, as well as a list of arches where it is known
> > > to work, should work, almost works, fails utterly.
> > 
> > It is not only arches, but also combinations of features:
> > 
> > With initrd-tools, running 2.4-x when installing a 2.6-x kernel
> > causes the tool to switch from "dep" to "most" because (I believe)
> > it cannot probe kernel module dependencies. Same situation will
> > currently cause yaird to fail completely,as it requires sysfs and
> > udev support in the running kernel.
> 
> We don't care about 2.4 kernels, and we don't care about
> initrd-tools, the choice is between intiramfs-tools and yaird, i
> favor a solution where this choice can be left to the user.

We do care about upgrading from sarge (that installed 2.4.x by default
on at least the archs I tried) and etch (that I believe will use 2.6
by default on most or all arches), don't we?

Added that limitation to the wiki page.


Sven: Please don't cc me - I am subscribed to the list :-)


 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDROsYn7DbMsAkQLgRAmm+AJ9+rQD+DTWdfkpCeytziteUY3Sz/wCgm1nZ
zzN/ciVvzRIIv1tS6BODgfs=
=xyF0
-END PGP SIGNATURE-

Re: 2.6.13, experimental and 2.6.14-rc ...

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 05 Oct 2005 16:49:54 -0600
dann frazier <[EMAIL PROTECTED]> wrote:

> On Thu, 2005-10-06 at 00:22 +0200, Marco Amadori wrote:
> > Alle 23:13, mercoledì 5 ottobre 2005, dann frazier ha scritto:
> > 
> > > And also, what will be the best way to migrate?  Should we make a
> > > new initrd-tools package that provides a /usr/sbin/mkinitrd
> > > script that selects a backend and performs any necessary argument
> > > munging? (I think someone suggested this before...). This would
> > > be a clean upgrade path, and would work with existing kernel debs
> > > that are out there, and wouldn't require asking the user to
> > > update their kernel-img.conf file (but they could do so, if they
> > > wanted).  It also wouldn't require a kernel-package mods.

I believe that someone was me:
http://lists.debian.org/debian-boot/2005/09/msg00330.html


> Not that we have to track this on a wiki, but wikis are my hammer
> these days - and this is just the latest nail.

I am a WikiFan too - and it certainly helps that the debian.org wiki
uses my favorite - MoinMoin :-)

Have updated with more options and more info. Someone more
knowledgeable about initramfs-tools please add to the comparison what
makes that tool great (to help choose the best default when we hopefully
end up with both tools working flawlessly in all aspects ;-) ).


 - Jonas

P.S.

No need to cc me - I am subscribed to the kernel list.

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDROeon7DbMsAkQLgRAq62AJ4oGsLhiAjFhN2vgiu9UDxTW8rmsgCfSF8r
WQt0ef2G33EsOXL117MzP7U=
=+/Tv
-END PGP SIGNATURE-

Re: 2.6.13, experimental and 2.6.14-rc ...

[Sven Luther]

On Wed, Oct 05, 2005 at 08:19:14PM +0200, Jonas Smedegaard wrote:
> -BEGIN PGP SIGNED MESSAGE-
> > > If not, why?
> > 
> > I guess generic miscomprehension, or whatever. The fact that ubuntu
> > uses initramfs-tools for example, and so on.
> 
> I would guess similarly. My interest was (and still is) actual concrete
> reasons from those (if any) not interested.
> 
> Silence as response to both questions (from all but you and I) I dare
> interpret as "we have already decided on initramfs-tools and are either
> too lazy or too busy to even shed light on the issues we have with
> yaird".

Please interpret it as too busy to reply right now, as many in the kernel team
are over-worked with RL stuff these days :)

> > I think what would be of most interest is a technical description of
> > both solutions, as well as a list of arches where it is known to
> > work, should work, almost works, fails utterly.
> 
> It is not only arches, but also combinations of features:
> 
> With initrd-tools, running 2.4-x when installing a 2.6-x kernel causes
> the tool to switch from "dep" to "most" because (I believe) it cannot
> probe kernel module dependencies. Same situation will currently cause
> yaird to fail completely,as it requires sysfs and udev support in the
> running kernel.

We don't care about 2.4 kernels, and we don't care about initrd-tools, the
choice is between intiramfs-tools and yaird, i favor a solution where this
choice can be left to the user.

> The features - mount types and kernel command line options - supported
> or planned by yaird is listed upstream here:
> http://www.xs4all.nl/~ekonijn/yaird/yaird.html
> 
> 
> Generally, yaird has a minimalistic approach, wanting to include only
> what is known to be needed - whereas it seems initrd-tools and
> initramfs-tools both include all except what is known not to be needed.
> 
> 
> > The fact that yaird doesn't use klibc seems to be a nice feature on
> > those arches where klibc is still broken.
> 
> Another point is size: Do all of those arches with a working klibc
> support the large initramfs'es generated currently by initramfs-tools?
> 
> And do I remember correctly that some tools in the initramfs using klibc
> and others (like mdadm and lvm) using glibc can cause trouble?
> 
> 
> > I believe the best solution is to leave the choice to the user, with
> > a sane default depending on the arch/subarch used.
> 
> I agree. Similar to the choice of LILO or GRUB (or other bootloaders
> when relevant).

Except done right, and not the mess that the bootloader selection is right now
:)

Friendly,

Sven LUther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#332228: kernel-source-2.4.27: ipt_recent bug: stops working after a 250 days uptime

[Ludovic Drolez]

On Thu, Oct 06, 2005 at 10:39:50AM +0900, Horms wrote:
> I have talked with upstream, and Juergen Kreidleder who originally
> discovered this bug about this problem. Unfortunately there is no patch
> that fixes this problem that upstream is comfortable, so I would rather

But replacing jiffies with seconds seems to be nice...

Cheers,

-- 
Ludovic Drolez.

http://www.palmopensource.com   - The PalmOS Open Source Portal
http://www.drolez.com  - Personal site - Linux and PalmOS stuff


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]