Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
wayland
wayland
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 96
    • Issues 96
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 25
    • Merge Requests 25
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • wayland
  • waylandwayland
  • Issues
  • #74

Closed
Open
Opened Jan 28, 2019 by Victor Berger@levans

State corruption on destruction race with server-created objects

So, this is kind of an edge case, but I found a sequence of events that consistently corrupt the protocol state, based on the races described in https://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html

The flow is:

  • a client creates a wl_data_device
  • the server creates a wl_data_offer and sends it to the client
  • the client concurrently destroys the wl_data_offer via its release request

Now, seeing the code from wayland-client here: https://gitlab.freedesktop.org/wayland/wayland/blob/master/src/wayland-client.c#L1349-1361 we see that it silently drops events to zombie objects, meaning the event creating the newid wl_data_offer is never processed, and this id is never inserted in the server map.

Now next time the server tries to create a wl_data_offer, it'll allocate the next id in its server space and send it. But from the client point of view, this id is not a valid id, as it is not 1 past the last used, but 2 past it (as the previous never got inserted). And so this happens:

not a valid new object id (4278190081), message data_offer(n)

I guess the fix should be that wayland-client should still allocate new ids in events to zombie objects, even if it means leaking them in the long run?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: wayland/wayland#74