Bug 199172

Summary:	CVE-2006-3468 Bogus FH in NFS request causes DoS in file system code
Product:	Red Hat Enterprise Linux 4	Reporter:	Marcel Holtmann <holtmann>
Component:	kernel	Assignee:	Eric Sandeen <esandeen>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	4.0	CC:	jbaron, lwang, security-response-team, staubach, steved
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	impact=important,source=lkml,reported=20060717,public=20060717
Fixed In Version:	RHSA-2006-0617	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-08-22 18:51:45 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	176344

Description Marcel Holtmann 2006-07-17 18:25:22 UTC

Reported by James McKenzie on LKML:

http://bugzilla.kernel.org/show_bug.cgi?id=6828

We found this rather surprising behaviour when debugging a
network card for one of our embedded systems. There was a
bus problem that occasionally caused the network card to
place random data in the outgoing packets. We were using
NFS root, as we hadn't written drivers for the block
devices yet, and discovered our Linux NFS servers getting
ext3 errors. It turned out that the 3com cards we have in
the servers lie about checking UDP checksums, and passed
the rubbish to knfsd where it was causing the problem. 

Here's an example one of our widgets (dcm503) is talking
to an NFS server (dufftown)

17:28:38.535011 dcm503.guralp.local.984095109 > dufftown.guralp.local.nfs: 116 
lookup fh Unknown/1 "" (DF) (ttl 64, id 0, len 144)
                         4500 0090 0000 4000 4011 3d45 0a52 01fa
                         c0a8 3024 03ff 0801 007c 8e9c 3aa8 1985
                         0000 0000 0000 0002 0001 86a3 0000 0002
                         0000 0004 0000 0001 0000 001c 028f 5b0c
                         0000 0006 6463 6d35 3033 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0100 0001 0021 0003 3d26 3d00 4a2f ffff
                         3d00 2c08 c923 0000 0000 0000 0000 0000
                         0000 0000 000a 6d6f 756e 7470 6f69 6e74

so what's happened here is 4a2f ffff should have been 4a2f
xxxx but the network card has missed the clock on the bus
and gotten ffff instead

nfsd_dispatch: vers 2 proc 4
nfsd: LOOKUP   32: 01000001 03002100 003d263d ffff2f4a 082c003d 000023c9
nfsd: nfsd_lookup(fh 32: 01000001 03002100 003d263d ffff2f4a 082c003d 
000023c9, )
nfsd: fh_verify(32: 01000001 03002100 003d263d ffff2f4a 082c003d 000023c9)

so here the client does a V2 lookup with a DH which has
gotten screwed up by my clients network card, this is
received by my server, gets past the UDP checksum code
(thank you 3com) and ends up at knfsd.

knfsd passes this to fh_verify which decodes it to be hde3
and inode 4294913866 (0xffff2f4a)

that then gets passed to ext3 which then panics.

EXT3-fs error (device hde3): ext3_get_inode_block: bad inode number: 
4294913866

marks the file system as containing an error, and remounts
the system read only.

Obviously this is sub optimal, and a fairly horrid DoS
since anyone can craft a UDP packet, with a bogus FH in
it. Whilst this is for V2_LOOKUP it works for all of the
V2 procedures we tried.

Comment 3 Marcel Holtmann 2006-07-18 14:58:01 UTC

The discussion thread on LKML can be found here:

http://lkml.org/lkml/2006/7/17/41

Comment 9 Alec Berryman 2006-07-21 02:31:04 UTC

Proposed patch: http://lkml.org/lkml/2006/7/20/1

Comment 15 Jason Baron 2006-08-07 18:51:40 UTC

committed in stream E5 build 42.0.1. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

Comment 18 Red Hat Bugzilla 2006-08-22 18:51:52 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0617.html

Comment 19 Jason Baron 2006-08-30 17:49:26 UTC

committed in stream U5 build 42.4. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

Comment 20 Jason Baron 2007-03-28 20:17:40 UTC

*** Bug 234366 has been marked as a duplicate of this bug. ***