Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 636411 - (CVE-2010-3699) CVE-2010-3699 kernel: guest->host denial of service from invalid xenbus transitions
CVE-2010-3699 kernel: guest->host denial of service from invalid xenbus trans...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
reported=20100922,public=20101124,sou...
: Security
Depends On: 635999 636412
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-22 03:42 EDT by Eugene Teo (Security Response)
Modified: 2018-08-28 17:51 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0004 normal SHIPPED_LIVE Important: kernel security, bug fix, and enhancement update 2011-01-04 11:52:05 EST

  None (edit)
Description Eugene Teo (Security Response) 2010-09-22 03:42:55 EDT
Description of problem:
Tearing down incorrectly a tap:aio:... device causes the backend to hang and
prevents further management operations in the host (including listing and
creating domains).

Version-Release number of selected component (if applicable):
Present since forever.

How reproducible:
100%

Actual results:
The backend of the domain's xvdb device will never be torn down, and the domain
will remain in "xm list" as a zombie until xend is restarted.  Even then, most
"xm" commands will not work anymore in the host.

The following messages will appear in /var/log/messages:

kernel: INFO: task xenwatch:21 blocked for more than 120 seconds.
kernel: xenwatch      D ffff8801de591100     0    21     19    22       (L-TLB)
kernel:  ffff8801de5abdc0  0000000000000246  0000000000000009  ffff8801de591100 
kernel:  0000000000000009  ffff8801de591100  ffff8800a8476040  0000000000000924 
kernel:  ffff8801de5912e8  ffffffffffffffff 
kernel: Call Trace:
kernel:  [<ffffffff802893ce>] enqueue_task+0x41/0x56
kernel:  [<ffffffff8029d110>] keventd_create_kthread+0x0/0xc4
kernel:  [<ffffffff88755901>] :blktap:tap_blkif_free+0x72/0x97
kernel:  [<ffffffff8029d328>] autoremove_wake_function+0x0/0x2e
kernel:  [<ffffffff887555e2>] :blktap:tap_frontend_changed+0x1d5/0x231
kernel:  [<ffffffff803ba494>] xenbus_read_driver_state+0x26/0x3b

Expected results:
The backend can tolerate guests with erroneous backend behavior.

Additional info:
The root cause of the failure is that in step 4a we skip the "Closing" phase of
the xenbus protocol, where the kernel thread is released:

        case XenbusStateClosing:
                if (be->blkif->xenblkd) {
                        kthread_stop(be->blkif->xenblkd);
                        be->blkif->xenblkd = NULL;
                }
                tap_blkif_free(be->blkif);

This code is never executed.  Then, at step 4d, another thread is started.

At step 5, the frontend goes to the Closing state, and the code above _is_
executed.  The second xenblkd thread _is_ stopped when the Closing state is
reached, but the leaked one keeps a reference to be->blkif and thus
tap_blkif_free hangs.  The whole xenwatch process then cannot run anymore.
Comment 2 Eugene Teo (Security Response) 2010-11-25 00:36:43 EST
Upstream commit:
http://xenbits.xen.org/linux-2.6.18-xen.hg?rev/59f097ef181b
Comment 4 errata-xmlrpc 2011-01-04 11:52:12 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2011:0004 https://rhn.redhat.com/errata/RHSA-2011-0004.html

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