Bug 438758 - wrong kunmap call in nfs_xdr_readlinkres
Summary: wrong kunmap call in nfs_xdr_readlinkres
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Fabio Olive Leite
QA Contact: Martin Jenner
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-24 21:43 UTC by Fabio Olive Leite
Modified: 2018-10-20 00:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-17 03:19:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to use kunmap_atomic instead of kunmap (887 bytes, patch)
2008-03-24 21:43 UTC, Fabio Olive Leite
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0973 normal SHIPPED_LIVE Important: kernel security and bug fix update 2008-12-17 03:18:50 UTC

Description Fabio Olive Leite 2008-03-24 21:43:42 UTC
Description of problem:

Quite a while ago an nfs_xdr_readlinkres bug when receiving really large
symlinks from the server was fixed, but the fix uses the wrong kind of kunmap.

Version-Release number of selected component (if applicable):

kernel-2.4.21-54.EL contains it.

How reproducible:

Apparently 100% if we access a symlink of size PATH_MAX in the NFS server.

Steps to Reproduce:

Set up an NFS (v2 or v3) server exporting a volume containing a symlink of
PATH_MAX characters in size. Access the link, and an oops should occur. The
current oops is not because of the overflow caused by the symlink, but because
kunmap_atomic should have been used in the fix for giant symlinks.
  
Additional info:

Patch provided. It's different upstream, but our fix that included this bug is
already different from upstream anyway.

Comment 1 Fabio Olive Leite 2008-03-24 21:43:42 UTC
Created attachment 298955 [details]
Patch to use kunmap_atomic instead of kunmap

Comment 2 Fabio Olive Leite 2008-03-24 21:47:03 UTC
Also, I wonder if we should include a test for NFS3_MAXPATHLEN to
nfs3_xdr_readlinkres, since the corresponding v2 nfs_xdr_readlinkres has a test
for NFS2_MAXPATHLEN.

Comment 3 Peter Staubach 2008-03-25 15:33:50 UTC
Regarding Comment #2 -- This is iffey.  The NFSv2 protocol actually
defined limits on thelength of pathnames and the contents of symbolic
links and such.  The NFSv3 protocol does not place any limits on
these lengths, but instead, allows the server or client to use their
own limits.  The error, NFS3ERR_NAMETOOLONG, was added so that a
server can inform the client that a name that was passed was too
long for it to handle.  The client, when it sees something which is
too long for it to handle, should return the appropriate error to the
user level.

Comment 4 Fabio Olive Leite 2008-03-25 21:59:52 UTC
OK, the current NFSv3 test of "what fits on the allocated page" is probably as
good as it gets, then. Thanks for the information.

Comment 5 Fabio Olive Leite 2008-03-26 01:44:58 UTC
This bug originated from a broken fix to bug 169230.

Comment 6 Fabio Olive Leite 2008-03-26 14:33:10 UTC
Now that I look harder at the old bug, I noticed that the code patched in bug
169230 did use kmap_atomic (looking at 2.4.21-37.8.EL), while the upstream patch
quoted there doesn't. So it's likely that the RHEL code was changed to use
kmap_atomic for some other reason, and the upstream patch applied with some
fuzzyness but inserted a plain kunmap call, instead of a kunmap_atomic.

I'm going to post the patch now, as I'm convinced it's the right thing to do.

Comment 7 Fabio Olive Leite 2008-03-26 14:54:16 UTC
Patch posted to rhkernel-list.

Comment 8 Fabio Olive Leite 2008-03-27 13:30:42 UTC
Just tested kernel-2.4.21-53.EL, and it seems to handle a 4095-char symlink just
fine. Perhaps we need memory pressure as well to trigger the kunmap issue?

Server:
$ ln -s $(perl -e 'print "A" x 4095;') foo

Client:
# ls -l
ls: cannot read symbolic link foo: Input/output error
total 4
lrwxrwxrwx    1 11208    11208        4095 Mar 27 09:22 foo

# uname -r
2.4.21-53.ELsmp


Comment 13 RHEL Product and Program Management 2008-05-28 00:07:43 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 14 Don Howard 2008-11-04 20:01:13 UTC
A patch addressing this issue has been included in build 2.4.21-58.EL.

Comment 18 errata-xmlrpc 2008-12-17 03:19:27 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 therefore 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-2008-0973.html


Note You need to log in before you can comment on or make changes to this bug.