Bug 2203906 - client: possibly wild pointer read when reconnection to mds
Summary: client: possibly wild pointer read when reconnection to mds
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat Storage
Component: CephFS
Version: 5.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 6.1z1
Assignee: Venky Shankar
QA Contact: Hemanth Kumar
Akash Raj
URL:
Whiteboard:
Depends On:
Blocks: 2221020
TreeView+ depends on / blocked
 
Reported: 2023-05-15 14:52 UTC by Venky Shankar
Modified: 2023-08-03 16:45 UTC (History)
4 users (show)

Fixed In Version: ceph-17.2.6-90.el9cp
Doc Type: Bug Fix
Doc Text:
.Structure variables are no longer stale or unsafe when accessed after session reconnection Previously, the Ceph File System user-space clients could access stale/unsafe structure variables when rebuilding a request and this would lead to the clients misbehaving sometimes after reconnecting to the Ceph Manager daemons while re-issuing requests. With this fix, the structure variables are no longer stale or unsafe when accessed after session reconnection. This is ensured by deep-copying them instead of shallow-copying and the Ceph File System (CephFS) user-space clients work as expected.
Clone Of:
Environment:
Last Closed: 2023-08-03 16:45:09 UTC
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Ceph Project Bug Tracker 59514 0 None None None 2023-05-15 14:52:35 UTC
Red Hat Issue Tracker RHCEPH-6661 0 None None None 2023-05-15 14:54:00 UTC
Red Hat Product Errata RHBA-2023:4473 0 None None None 2023-08-03 16:45:54 UTC

Description Venky Shankar 2023-05-15 14:52:35 UTC
Comment 1 RHEL Program Management 2023-05-15 14:52:46 UTC 
Please specify the severity of this bug. Severity is defined here:
https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity.
Comment 2 Venky Shankar 2023-05-15 14:54:32 UTC 
Note to QE - verification for this can be done through running the build through sanity.

Problem:

We use `shallow_copy`(24279ef8) for `MetaRequest::set_caller_perms ` in `Client::make_request` but indeed the lifetime of `MetaRequest` is possible to longer than a `syscall`, because the request will return when they received `unsafe_reply` with release the `UserPerms`, but the `MetaRequest` will not unregister immediately, we have to rebuild the `MClientRequest` when mds reboot, in `send_reconnect`, and that's will access `MetaRequest::perms::gids` again.

int Client::make_request(MetaRequest* request, const UserPerm& perms,
                         InodeRef* ptarget, bool* pcreated, mds_rank_t use_mds,
                         bufferlist* pdirbl)
{
    ...
    request->set_caller_perms(perms);

struct MetaRequest
{
    ...
    void set_caller_perms(const UserPerm& _perms) {
        perms.shallow_copy(_perms);
Comment 12 errata-xmlrpc 2023-08-03 16:45:09 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat Ceph Storage 6.1 Bug Fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:4473
Note You need to log in before you can comment on or make changes to this bug.