Hi,
here is the fourth hotfix for 2.4.32 and older kernels. There are 9 new
fixes, 5 of which are security-related, 1 memory leak, and 3 minor bugs :
- 2.4.32-CVE-2006-0741-always-check-that-rips-are-canonical-1 (Andi Kleen)
- 2.4.32-CVE-2006-1524-fix-shm-mprotect-1 (Hugh Dickins)
- 2.4.32-CVE-2006-1056-i386-x86_64-x87-information-leak-1 (Andi Kleen)
- 2.4.32-via-rhine-zero-pad-short-packets-1 (Craig Brind)
- 2.4.32-CVE-2006-1864-smbfs-escape-chroot-1 (Olaf Kirch)
- 2.4.32-netfilter-ipt_recent-memleak-1 (Jesper Juhl)
- 2.4.32-nfs-cache-consistency-with-mmap-1 (Jeff Layton)
- 2.4.32-vlan_ioctl-missing-checks-1 (Mika Kukkonen)
- 2.4.32-quota_v2-module-taints-the-kernel-1 (Marek Szuba)
This leads to the following number of patches per kernel :
Version | New | Total
--------+-----+------
2.4.28 | 9 | 170
2.4.29 | 9 | 167
2.4.30 | 9 | 101
2.4.31 | 9 | 88
2.4.32 | 9 | 38
--------+-----+------
Please note that two of those patches are not in mainline yet (merged at the
last minute) : the SMBFS fix (CVE-2006-1864, which is fixed in 2.6.16.14) and
the ipt_recent memory leak.
I've built it with all modules on x86-smp but not booted it yet. The detailed
changelog follows.
Please use the links below to download it :
hotfixes home : http://linux.exosec.net/kernel/2.4-hf/
last version : http://linux.exosec.net/kernel/2.4-hf/LATEST/LATEST/
RSS feed : http://linux.exosec.net/kernel/hf.xml
build results : http://bugsplatter.mine.nu/test/linux-2.4/ (Grant's site)
GIT : http://w.ods.org/kernel/2.4/patches-2.4-hf.git/
GITWEB : http://w.ods.org/git/?p=patches-2.4-hf.git;a=summary
Changelog from 2.4.32-hf32.3 to 2.4.32-hf32.4
---------------------------------------
'+' = added ; '-' = removed
+ 2.4.32-CVE-2006-0741-always-check-that-rips-are-canonical-1 (Andi Kleen)
This works around a problem in handling non canonical RIPs on SYSRET on
Intel CPUs. They report the #GP on the SYSRET, not the next instruction
as Linux expects it. With these changes this path should never see a non
canonical user RIP. This is CVE-2006-0741. Roughly based on a patch by
Ernie Petrides, but redone by AK.
+ 2.4.32-CVE-2006-1524-fix-shm-mprotect-1 (Hugh Dickins)
shmat stop mprotect from giving write permission to a readonly
attachment.
+ 2.4.32-CVE-2006-1056-i386-x86_64-x87-information-leak-1 (Andi Kleen)
AMD K7/K8 CPUs only save/restore the FOP/FIP/FDP x87 registers in FXSAVE
when an exception is pending. This means the value leak through context
switches and allow processes to observe some x87 instruction state of
other processes. This is CVE-2006-1056. The problem was discovered
originally by Jan Beulich. Richard Brunner provided the basic code for
the workarounds with contributions from Jan.
+ 2.4.32-via-rhine-zero-pad-short-packets-1 (Craig Brind)
Fixes Rhine I cards disclosing fragments of previously transmitted
frames in new transmissions.
Before transmission, any socket buffer (skb) shorter than the ethernet
minimum length of 60 bytes was zero-padded. On Rhine I cards the data
can later be copied into an aligned transmission buffer without copying
this padding. This resulted in the transmission of the frame with the
extra bytes beyond the provided content leaking the previous contents of
this buffer on to the network. Now zero-padding is repeated in the local
aligned buffer if one is used.
+ 2.4.32-CVE-2006-1864-smbfs-escape-chroot-1 (Olaf Kirch)
Initial work and description from Olaf Kirch for kernel 2.6 :
Mark Moseley reported that a chroot environment on a SMB share can be
left via "cd ..\\". Similar to CVE-2006-1863 issue with cifs, this fix
is for smbfs (CVE-2006-1864). Steven French <[email protected]> wrote:
Looks fine to me. This should catch the slash on lookup or equivalent,
which will be all obvious paths of interest. Back-ported from 2.6 to 2.4
by Willy Tarreau.
+ 2.4.32-netfilter-ipt_recent-memleak-1 (Jesper Juhl)
The Coverity checker spotted that we may leak 'hold' in
net/ipv4/netfilter/ipt_recent.c::checkentry() when the following
is true :
if (!curr_table->status_proc) {
...
if(!curr_table) {
...
return 0; <-- here we leak.
Simply moving an existing vfree(hold); up a bit avoids the possible leak.
+ 2.4.32-nfs-cache-consistency-with-mmap-1 (Jeff Layton)
A customer of Red Hat reported a problem with cache invalidation when
using mmapped files over NFS with the 2.4 kernel. This patch fixes this
by checking whether the clean_pages list for the inode is empty after
invalidate_inode_pages is called. If it's not then we set a flag so on
the next pass through it automatically flags the data as invalid.
+ 2.4.32-vlan_ioctl-missing-checks-1 (Mika Kukkonen)
In vlan_ioctl_handler() the code misses couple checks for
error return values. The same patch was merged into 2.6.
+ 2.4.32-quota_v2-module-taints-the-kernel-1 (Marek Szuba)
Apparently the quota_v2 module in 2.4 still lacks the licence macro
and taints the kernel, even though the same module in 2.6 is correctly
tagged as GPL. In case it makes things any easier, I am enclosing an
appropriate patch.
--
Willy Tarreau - http://w.ods.org/
EXOSEC - ZAC des Metz - 3 Rue du petit robinson - 78350 JOUY EN JOSAS
N?Indigo: 0 825 075 510 - Accueil: +33 1 72 89 72 30 - Fax: +33 1 72 89 80 19
Site web : http://www.exosec.fr/
Hi,
here is the fifth hotfix for 2.4.32 and older kernels. There are 8 new
fixes, among which 1 security fix, 1 possible panic and one potential
memory leak, and 5 minor bugs :
- 2.4.32-CVE-2006-2444-netfilter-snmp-nat-mem-corruption-1 (Patrick McHardy)
- 2.4.32-memleak-on-corrupted-ext3-journal-1 (Theodore Ts'o)
- 2.4.32-avoid-panic-on-corrupted-ext3-journal-1 (Willy Tarreau)
- 2.4.32-fix-usb-fdd-without-partitions-1 (Gilles Espinasse)
- 2.4.32-expire-stale-arp-entries-1 (Pradeep Vincent)
- 2.4.32-ext2-update-inode-ctime-on-rename-1 (Willy Tarreau)
- 2.4.32-ext3-link-unlink-race-1 (Vadim Egorov)
- 2.4.32-ver_linux-binutils-version-reporting-1 (Joshua Kwan)
This leads to the following number of patches per kernel :
Version | New | Total
--------+-----+------
2.4.28 | 8 | 178
2.4.29 | 8 | 175
2.4.30 | 8 | 109
2.4.31 | 8 | 96
2.4.32 | 8 | 46
--------+-----+------
Please note that three of those patches are not in mainline yet (but
queued) : the netfilter fix (CVE-2006-2444), the ext3-memleak and
the ext3 potential panic. I particularly thank Chris Wright for having
notified us about the netfilter bug we had missed.
I've built it with all modules on x86-smp but not booted it. The
detailed changelog follows. One thing to note is that Jari Ruusu
convinced me to reconciliate with GPG and to sign the files with it.
I don't know if I have done everything right, but I've signed every
.gz file and provided a detached ascii signature. Please do not hesitate
to tell me if I did something wrong. Fingerprint at the end of the mail.
Please use the links below :
hotfixes home : http://linux.exosec.net/kernel/2.4-hf/
last version : http://linux.exosec.net/kernel/2.4-hf/LATEST/LATEST/
RSS feed : http://linux.exosec.net/kernel/hf.xml
build results : http://bugsplatter.mine.nu/test/linux-2.4/ (Grant's site)
GIT : http://w.ods.org/kernel/2.4/patches-2.4-hf.git/
GITWEB : http://w.ods.org/git/?p=patches-2.4-hf.git;a=summary
Regards,
Willy
--
Changelog from 2.4.32-hf32.4 to 2.4.32-hf32.5
---------------------------------------
'+' = added ; '-' = removed
+ 2.4.32-CVE-2006-2444-netfilter-snmp-nat-mem-corruption-1 (Patrick McHardy)
CVE-2006-2444 - Potential remote DoS in SNMP NAT helper.
Fix memory corruption caused by snmp_trap_decode which may free
random memory when snmp_trap_decode fails. The corruption can be
triggered remotely when the ip_nat_snmp_basic module is loaded
and traffic on port 161 or 162 is NATed.
+ 2.4.32-memleak-on-corrupted-ext3-journal-1 (Theodore Ts'o)
Fix memory leak when the ext3's journal file is corrupted
+ 2.4.32-avoid-panic-on-corrupted-ext3-journal-1 (Willy Tarreau)
Backport from 2.6 of a patch from Andrew Morton : Don't panic if the
journal superblock is wrecked: just fail the mount.
+ 2.4.32-fix-usb-fdd-without-partitions-1 (Gilles Espinasse)
When an USB flash disk is formatted as a floppy (without partitions),
random partitions appear in /proc/partitions depending on the code and
data used by the boot loader at the offset where the partition table
is expected. Such layout appears when Windows is used to format the USB
stick, or when putting a boot-loader such as syslinux on an device. This
patch is a back-port of the 2.6 fix. Carefully tested, works as expected.
+ 2.4.32-expire-stale-arp-entries-1 (Pradeep Vincent)
In 2.4.21, arp code uses gc_timer to check for stale arp cache
entries. In 2.6, each entry has its own timer to check for stale arp
cache. 2.4.29 to 2.4.32 kernels (atleast) use neither of these timers.
This causes problems in environments where IPs or MACs are reassigned
- saw this problem on load balancing router based networks that use
VMACs. Tested this code on load balancing router based networks as
well as peer-linux systems.
+ 2.4.32-ext2-update-inode-ctime-on-rename-1 (Willy Tarreau)
The ext2fs filesystem on 2.2 and 2.6, as well as other filesystems
on 2.4 update the inode ctime on rename(). When this fix was applied
to 2.2.13, it was applied to the ext3 tree at the same time, but the
ext2 tree was forgotten. It was recently fixed in 2.6, but 2.4 was
forgotten again. First reported by Chris Siebenmann on 10 Jan 2004.
+ 2.4.32-ext3-link-unlink-race-1 (Vadim Egorov)
The problem happens when link and unlink are invoked simultaneously on
the same inode on ext3 filesystem. In this case ext3_unlink may
decrement i_nlink to 0 and put this inode into the in-memory orphan
list, while ext3_link will increment i_nlink back to 1 having the inode
in the orphan list. Thus the system ends up having an inode with
i_nlink == 1 in the orphan list. When this inode gets unused later it
the memory might get released to the free pool and then be used for
some other purpose, most likely some other inode. From this point on
any operation on the orphan list may result in modification of the
list_head that could alredy be used to store some other date.
+ 2.4.32-ver_linux-binutils-version-reporting-1 (Joshua Kwan)
The 'ver_linux' script expects 'ld' to output a line starting with
'BFD', while recent versions of 'ld' print 'GNU ld'. The effect is
that binutils version is not listed in reports based on ver_linux.
--
Willy Tarreau - http://w.ods.org/
PGP Fingerprint : 72C2 A394 02EA F546 BA6F A7B1 E82C B631 848A 1004
EXOSEC - ZAC des Metz - 3 Rue du petit robinson - 78350 JOUY EN JOSAS
N?Indigo: 0 825 075 510 - Accueil: +33 1 72 89 72 30 - Fax: +33 1 72 89 80 19
Site web : http://www.exosec.fr/
On Thu, 25 May 2006 15:34:27 +0200, Willy TARREAU <[email protected]> wrote:
>Hi,
>
>here is the fifth hotfix for 2.4.32 and older kernels. There are 8 new
>fixes, among which 1 security fix, 1 possible panic and one potential
>memory leak, and 5 minor bugs :
Not my day... Built kernel for 7 targets on 5 machines, each target
gave same kernel panic on reboot. downloaded the patch again, it is
same as first download. started over with new source tree, nada...
copied by hand:
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Unable to handle kernel NULL pointer dereference at virtual address 00000088 printing eip:
c013ee43
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c013ee43>] Not tainted
EFLAGS: 00010246
eax: 00000088 ebx: c19bb5c0 ecx: 00000088 edx: f7bf0005
esi: f7e3c508 edi: c19bb5c0 ebp: f7e3c480 esp: f7e6bf18
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 1, stackpage=f7e6b000)
Stack: c19bb5c0 00000000 c19bb5c0 f7bf0000 f7e6bf3c c19bb5c0 c013f056 f7e3c480
c19bb5c0 c19bb440 c19ac140 f7bf0005 00000004 01c0d8cc 00000010 00000000
c013e727 00000803 c02a18f6 c0105000 0008e000 c0302bfb c02a18f6 f7bf0000
Call Trace: [<c013f056>] [<c013e727>] [<c0105000>] [<c013e890>] [<c01051f3>]
[<c0105085>] [<c010568b>] [<c0105070>]
Code: ff 08 0f 88 8f 16 00 00 8b 5f 08 85 db 74 0c 8b 47 0c 39 68
<0>Kernel panic: Attempted to kill init!
I'd like to seriously damage the person who invented [<...>]
display format after typing that lot in ;)
This is from sempro: <http://bugsplatter.mine.nu/test/linux-2.4/sempro/>
make oldconfig from working -hf32.4 (the config-* files on my site
are filtered with 'grep = config...')
Three build attempts on the fastest host, last build was with fresh
2.4.32 tree + patch :( Fails cold (power cycle) + warm boot...
No, I'm not going to type in from other boxen. Same failure, different
last 4 digits of the eip: value (c013????) Virtual addr 00000088 on all
I checked.
Grant.
Hi Grant,
On Fri, May 26, 2006 at 09:09:15PM +1000, Grant Coady wrote:
> On Thu, 25 May 2006 15:34:27 +0200, Willy TARREAU <[email protected]> wrote:
>
> >Hi,
> >
> >here is the fifth hotfix for 2.4.32 and older kernels. There are 8 new
> >fixes, among which 1 security fix, 1 possible panic and one potential
> >memory leak, and 5 minor bugs :
>
> Not my day... Built kernel for 7 targets on 5 machines, each target
> gave same kernel panic on reboot. downloaded the patch again, it is
> same as first download. started over with new source tree, nada...
Could you please pass it through ksymoops so that we get an idea about the
function causing this ? What was the last version not causing it ? hf32.4 ?
If so, then the bug must be in one of the 8 patches. I've reread them but
nothing obvious gets noticed.
This looks like a structure member gets accessed while a pointer is NULL,
if you always get 0x88... I would be it could come from
2.4.32-ext3-link-unlink-race-1, but that would be strange.
Thanks in advance,
Willy
> copied by hand:
>
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Unable to handle kernel NULL pointer dereference at virtual address 00000088 printing eip:
> c013ee43
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c013ee43>] Not tainted
> EFLAGS: 00010246
> eax: 00000088 ebx: c19bb5c0 ecx: 00000088 edx: f7bf0005
> esi: f7e3c508 edi: c19bb5c0 ebp: f7e3c480 esp: f7e6bf18
> ds: 0018 es: 0018 ss: 0018
> Process swapper (pid: 1, stackpage=f7e6b000)
> Stack: c19bb5c0 00000000 c19bb5c0 f7bf0000 f7e6bf3c c19bb5c0 c013f056 f7e3c480
> c19bb5c0 c19bb440 c19ac140 f7bf0005 00000004 01c0d8cc 00000010 00000000
> c013e727 00000803 c02a18f6 c0105000 0008e000 c0302bfb c02a18f6 f7bf0000
> Call Trace: [<c013f056>] [<c013e727>] [<c0105000>] [<c013e890>] [<c01051f3>]
> [<c0105085>] [<c010568b>] [<c0105070>]
>
> Code: ff 08 0f 88 8f 16 00 00 8b 5f 08 85 db 74 0c 8b 47 0c 39 68
> <0>Kernel panic: Attempted to kill init!
>
>
> I'd like to seriously damage the person who invented [<...>]
> display format after typing that lot in ;)
>
> This is from sempro: <http://bugsplatter.mine.nu/test/linux-2.4/sempro/>
> make oldconfig from working -hf32.4 (the config-* files on my site
> are filtered with 'grep = config...')
>
> Three build attempts on the fastest host, last build was with fresh
> 2.4.32 tree + patch :( Fails cold (power cycle) + warm boot...
>
> No, I'm not going to type in from other boxen. Same failure, different
> last 4 digits of the eip: value (c013????) Virtual addr 00000088 on all
> I checked.
>
> Grant.
On Fri, 26 May 2006 14:16:23 +0200, Willy Tarreau <[email protected]> wrote:
>Could you please pass it through ksymoops so that we get an idea about the
>function causing this ? What was the last version not causing it ? hf32.4 ?
Yes, hf32.4 okay, see: <http://bugsplatter.mine.nu/test/linux-2.4/>
>This looks like a structure member gets accessed while a pointer is NULL,
>if you always get 0x88... I would be it could come from
>2.4.32-ext3-link-unlink-race-1, but that would be strange.
Good guess! The previous version comment stripped .configs are
linked by machine name from the summary page above.
Localtime 23:28 so it will be overnight delay before I reply to
queries for further info ;)
grant@sempro:~$ ksymoops -v ~/linux/linux-2.4.32-hf32.5/vmlinux -m /boot/System.map-2.4.32-hf32.5 oops
ksymoops 2.4.11 on i686 2.6.16.17a. Options used
-v /home/grant/linux/linux-2.4.32-hf32.5/vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.6.16.17a/ (default)
-m /boot/System.map-2.4.32-hf32.5 (specified)
Error (regular_file): read_ksyms stat /proc/ksyms failed
ksymoops: No such file or directory
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel NULL pointer dereference at virtual address 00000088 printing eip:
c013ee43
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c013ee43>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000088 ebx: c19bb5c0 ecx: 00000088 edx: f7bf0005
esi: f7e3c508 edi: c19bb5c0 ebp: f7e3c480 esp: f7e6bf18
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 1, stackpage=f7e6b000)
Stack: c19bb5c0 00000000 c19bb5c0 f7bf0000 f7e6bf3c c19bb5c0 c013f056 f7e3c480
c19bb5c0 c19bb440 c19ac140 f7bf0005 00000004 01c0d8cc 00000010 00000000
c013e727 00000803 c02a18f6 c0105000 0008e000 c0302bfb c02a18f6 f7bf0000
Call Trace: [<c013f056>] [<c013e727>] [<c0105000>] [<c013e890>] [<c01051f3>]
[<c0105085>] [<c010568b>] [<c0105070>]
Code: ff 08 0f 88 8f 16 00 00 8b 5f 08 85 db 74 0c 8b 47 0c 39 68
>>EIP; c013ee43 <vfs_unlink+33/190> <=====
Trace; c013f056 <sys_unlink+b6/120>
Trace; c013e727 <vfs_mknod+c7/120>
Trace; c0105000 <_stext+0/0>
Trace; c013e890 <sys_mknod+110/180>
Trace; c01051f3 <prepare_namespace+73/140>
Trace; c0105085 <init+15/110>
Trace; c010568b <arch_kernel_thread+2b/40>
Trace; c0105070 <init+0/110>
Code; c013ee43 <vfs_unlink+33/190>
00000000 <_EIP>:
Code; c013ee43 <vfs_unlink+33/190> <=====
0: ff 08 decl (%eax) <=====
Code; c013ee45 <vfs_unlink+35/190>
2: 0f 88 8f 16 00 00 js 1697 <_EIP+0x1697>
Code; c013ee4b <vfs_unlink+3b/190>
8: 8b 5f 08 mov 0x8(%edi),%ebx
Code; c013ee4e <vfs_unlink+3e/190>
b: 85 db test %ebx,%ebx
Code; c013ee50 <vfs_unlink+40/190>
d: 74 0c je 1b <_EIP+0x1b>
Code; c013ee52 <vfs_unlink+42/190>
f: 8b 47 0c mov 0xc(%edi),%eax
Code; c013ee55 <vfs_unlink+45/190>
12: 39 68 00 cmp %ebp,0x0(%eax)
<0>Kernel panic: Attempted to kill init!
1 error issued. Results may not be reliable.
Thanks,
Grant.
[ I removed Jari who told me yesterday he did not need to be Cc'd ]
On Fri, May 26, 2006 at 11:28:51PM +1000, Grant Coady wrote:
> On Fri, 26 May 2006 14:16:23 +0200, Willy Tarreau <[email protected]> wrote:
>
> >Could you please pass it through ksymoops so that we get an idea about the
> >function causing this ? What was the last version not causing it ? hf32.4 ?
>
> Yes, hf32.4 okay, see: <http://bugsplatter.mine.nu/test/linux-2.4/>
>
> >This looks like a structure member gets accessed while a pointer is NULL,
> >if you always get 0x88... I would be it could come from
> >2.4.32-ext3-link-unlink-race-1, but that would be strange.
>
> Good guess! The previous version comment stripped .configs are
> linked by machine name from the summary page above.
Hmmm that's bad, this one has been merged into mainline.
It would look like dentry->d_inode is NULL here :
double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
I don't know how this can be fixed, though ! My first guess would be to
quickly revert the patch.
Marcelo, do you have Vadim Egorov's address ? I think he can help us on this,
after all it is his patch and he found explained the bug !
Right now I will release -hf32.6 quickly.
> Localtime 23:28 so it will be overnight delay before I reply to
> queries for further info ;)
>
> grant@sempro:~$ ksymoops -v ~/linux/linux-2.4.32-hf32.5/vmlinux -m /boot/System.map-2.4.32-hf32.5 oops
> ksymoops 2.4.11 on i686 2.6.16.17a. Options used
> -v /home/grant/linux/linux-2.4.32-hf32.5/vmlinux (specified)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.6.16.17a/ (default)
> -m /boot/System.map-2.4.32-hf32.5 (specified)
>
> Error (regular_file): read_ksyms stat /proc/ksyms failed
> ksymoops: No such file or directory
> No modules in ksyms, skipping objects
> No ksyms, skipping lsmod
> Unable to handle kernel NULL pointer dereference at virtual address 00000088 printing eip:
> c013ee43
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c013ee43>] Not tainted
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010246
> eax: 00000088 ebx: c19bb5c0 ecx: 00000088 edx: f7bf0005
> esi: f7e3c508 edi: c19bb5c0 ebp: f7e3c480 esp: f7e6bf18
> ds: 0018 es: 0018 ss: 0018
> Process swapper (pid: 1, stackpage=f7e6b000)
> Stack: c19bb5c0 00000000 c19bb5c0 f7bf0000 f7e6bf3c c19bb5c0 c013f056 f7e3c480
> c19bb5c0 c19bb440 c19ac140 f7bf0005 00000004 01c0d8cc 00000010 00000000
> c013e727 00000803 c02a18f6 c0105000 0008e000 c0302bfb c02a18f6 f7bf0000
> Call Trace: [<c013f056>] [<c013e727>] [<c0105000>] [<c013e890>] [<c01051f3>]
> [<c0105085>] [<c010568b>] [<c0105070>]
> Code: ff 08 0f 88 8f 16 00 00 8b 5f 08 85 db 74 0c 8b 47 0c 39 68
>
>
> >>EIP; c013ee43 <vfs_unlink+33/190> <=====
>
> Trace; c013f056 <sys_unlink+b6/120>
> Trace; c013e727 <vfs_mknod+c7/120>
> Trace; c0105000 <_stext+0/0>
> Trace; c013e890 <sys_mknod+110/180>
> Trace; c01051f3 <prepare_namespace+73/140>
> Trace; c0105085 <init+15/110>
> Trace; c010568b <arch_kernel_thread+2b/40>
> Trace; c0105070 <init+0/110>
>
> Code; c013ee43 <vfs_unlink+33/190>
> 00000000 <_EIP>:
> Code; c013ee43 <vfs_unlink+33/190> <=====
> 0: ff 08 decl (%eax) <=====
> Code; c013ee45 <vfs_unlink+35/190>
> 2: 0f 88 8f 16 00 00 js 1697 <_EIP+0x1697>
> Code; c013ee4b <vfs_unlink+3b/190>
> 8: 8b 5f 08 mov 0x8(%edi),%ebx
> Code; c013ee4e <vfs_unlink+3e/190>
> b: 85 db test %ebx,%ebx
> Code; c013ee50 <vfs_unlink+40/190>
> d: 74 0c je 1b <_EIP+0x1b>
> Code; c013ee52 <vfs_unlink+42/190>
> f: 8b 47 0c mov 0xc(%edi),%eax
> Code; c013ee55 <vfs_unlink+45/190>
> 12: 39 68 00 cmp %ebp,0x0(%eax)
>
> <0>Kernel panic: Attempted to kill init!
>
> 1 error issued. Results may not be reliable.
>
> Thanks,
> Grant.
Thank you very much Grant,
Willy
On Fri, May 26, 2006 at 04:07:31PM +0200, Willy Tarreau wrote:
> [ I removed Jari who told me yesterday he did not need to be Cc'd ]
>
> On Fri, May 26, 2006 at 11:28:51PM +1000, Grant Coady wrote:
> > On Fri, 26 May 2006 14:16:23 +0200, Willy Tarreau <[email protected]> wrote:
> >
> > >Could you please pass it through ksymoops so that we get an idea about the
> > >function causing this ? What was the last version not causing it ? hf32.4 ?
> >
> > Yes, hf32.4 okay, see: <http://bugsplatter.mine.nu/test/linux-2.4/>
> >
> > >This looks like a structure member gets accessed while a pointer is NULL,
> > >if you always get 0x88... I would be it could come from
> > >2.4.32-ext3-link-unlink-race-1, but that would be strange.
> >
> > Good guess! The previous version comment stripped .configs are
> > linked by machine name from the summary page above.
>
> Hmmm that's bad, this one has been merged into mainline.
> It would look like dentry->d_inode is NULL here :
>
> double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
>
> I don't know how this can be fixed, though ! My first guess would be to
> quickly revert the patch.
may_delete() should be called before attempting to grab victim's
i_zombie. Grant, can you please try the following?
diff --git a/fs/namei.c b/fs/namei.c
index 48bd26c..42cce98 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1479,19 +1479,20 @@ int vfs_unlink(struct inode *dir, struct
{
int error;
- double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
error = may_delete(dir, dentry, 0);
- if (!error) {
- error = -EPERM;
- if (dir->i_op && dir->i_op->unlink) {
- DQUOT_INIT(dir);
- if (d_mountpoint(dentry))
- error = -EBUSY;
- else {
- lock_kernel();
- error = dir->i_op->unlink(dir, dentry);
- unlock_kernel();
- }
+ if (error)
+ return error;
+
+ double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
+ error = -EPERM;
+ if (dir->i_op && dir->i_op->unlink) {
+ DQUOT_INIT(dir);
+ if (d_mountpoint(dentry))
+ error = -EBUSY;
+ else {
+ lock_kernel();
+ error = dir->i_op->unlink(dir, dentry);
+ unlock_kernel();
}
}
double_up(&dir->i_zombie, &dentry->d_inode->i_zombie);
On Fri, 26 May 2006 16:07:31 +0200, Willy Tarreau <[email protected]> wrote:
>[ I removed Jari who told me yesterday he did not need to be Cc'd ]
>
>On Fri, May 26, 2006 at 11:28:51PM +1000, Grant Coady wrote:
>> On Fri, 26 May 2006 14:16:23 +0200, Willy Tarreau <[email protected]> wrote:
>>
>> >Could you please pass it through ksymoops so that we get an idea about the
>> >function causing this ? What was the last version not causing it ? hf32.4 ?
>>
>> Yes, hf32.4 okay, see: <http://bugsplatter.mine.nu/test/linux-2.4/>
>>
>> >This looks like a structure member gets accessed while a pointer is NULL,
>> >if you always get 0x88... I would be it could come from
>> >2.4.32-ext3-link-unlink-race-1, but that would be strange.
>>
>> Good guess! The previous version comment stripped .configs are
>> linked by machine name from the summary page above.
>
>Hmmm that's bad, this one has been merged into mainline.
>It would look like dentry->d_inode is NULL here :
>
> double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
Too late last night for me to realise this, I don't use ext3! The Oops
came after all active partitions loaded, 'cos that's when the network
started (last good dmesg entries before oops).
That might explain why you didn't see this problem your site?
I use ext2 (for small partitions, floppy) and reiserfs 3.6 here,
they're compiled in and generally dos, vfat, ntfs, iso9660 as
modules where required.
Grant.
On Fri, 26 May 2006 15:27:58 -0300, Marcelo Tosatti <[email protected]> wrote:
>may_delete() should be called before attempting to grab victim's
>i_zombie. Grant, can you please try the following?
Yep, applied against linux-2.4.32-hf32.5, boots on sempro (the box I
gave the oops info for).
Guess I'll see .33-pre4 and a -hf32.7 soon?
Cheers,
Grant.
>
>diff --git a/fs/namei.c b/fs/namei.c
>index 48bd26c..42cce98 100644
>--- a/fs/namei.c
>+++ b/fs/namei.c
>@@ -1479,19 +1479,20 @@ int vfs_unlink(struct inode *dir, struct
> {
> int error;
>
>- double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
> error = may_delete(dir, dentry, 0);
>- if (!error) {
>- error = -EPERM;
>- if (dir->i_op && dir->i_op->unlink) {
>- DQUOT_INIT(dir);
>- if (d_mountpoint(dentry))
>- error = -EBUSY;
>- else {
>- lock_kernel();
>- error = dir->i_op->unlink(dir, dentry);
>- unlock_kernel();
>- }
>+ if (error)
>+ return error;
>+
>+ double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
>+ error = -EPERM;
>+ if (dir->i_op && dir->i_op->unlink) {
>+ DQUOT_INIT(dir);
>+ if (d_mountpoint(dentry))
>+ error = -EBUSY;
>+ else {
>+ lock_kernel();
>+ error = dir->i_op->unlink(dir, dentry);
>+ unlock_kernel();
> }
> }
> double_up(&dir->i_zombie, &dentry->d_inode->i_zombie);
On Sat, May 27, 2006 at 05:29:58AM +1000, Grant Coady wrote:
> On Fri, 26 May 2006 15:27:58 -0300, Marcelo Tosatti <[email protected]> wrote:
>
> >may_delete() should be called before attempting to grab victim's
> >i_zombie. Grant, can you please try the following?
>
> Yep, applied against linux-2.4.32-hf32.5, boots on sempro (the box I
> gave the oops info for).
Fine, that's good news !
> Guess I'll see .33-pre4 and a -hf32.7 soon?
Well, at least not hf32.7 since this fix was initially "minor". I'll
wait for a few more important ones to release another hotfix.
> Cheers,
> Grant.
Thanks for all your tests, Grant
Willy
> >
> >diff --git a/fs/namei.c b/fs/namei.c
> >index 48bd26c..42cce98 100644
> >--- a/fs/namei.c
> >+++ b/fs/namei.c
> >@@ -1479,19 +1479,20 @@ int vfs_unlink(struct inode *dir, struct
> > {
> > int error;
> >
> >- double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
> > error = may_delete(dir, dentry, 0);
> >- if (!error) {
> >- error = -EPERM;
> >- if (dir->i_op && dir->i_op->unlink) {
> >- DQUOT_INIT(dir);
> >- if (d_mountpoint(dentry))
> >- error = -EBUSY;
> >- else {
> >- lock_kernel();
> >- error = dir->i_op->unlink(dir, dentry);
> >- unlock_kernel();
> >- }
> >+ if (error)
> >+ return error;
> >+
> >+ double_down(&dir->i_zombie, &dentry->d_inode->i_zombie);
> >+ error = -EPERM;
> >+ if (dir->i_op && dir->i_op->unlink) {
> >+ DQUOT_INIT(dir);
> >+ if (d_mountpoint(dentry))
> >+ error = -EBUSY;
> >+ else {
> >+ lock_kernel();
> >+ error = dir->i_op->unlink(dir, dentry);
> >+ unlock_kernel();
> > }
> > }
> > double_up(&dir->i_zombie, &dentry->d_inode->i_zombie);