diff options
author | Brian J. Tarricone <brian@tarricone.org> | 2023-09-27 23:54:51 -0700 |
---|---|---|
committer | Brian J. Tarricone <brian@tarricone.org> | 2023-09-27 23:54:51 -0700 |
commit | eacb4cf6d290ba197be1ce6070cba172213e1fc4 (patch) | |
tree | e730b3cb58b67d3397664c25864dd03d1688beaf | |
parent | 1a731596c5bcd252d8796cacb59af8b20ceb914f (diff) |
Fix possible crash in server-decoration when surface destroyed
If the underlying surface is destroyed, but the client has not yet
destroyed the server decoration object, and then tries to call
request_mode() on it, the compositor will crash, because the
wlr_server_decoration struct has been freed, and the wl_resource's
user_data member has been NULLed out.
Yes, this is certainly an error for the client to do that, but I
shouldn't be able to write a buggy (or malicious) Wayland app that can
take down the entire compositor.
-rw-r--r-- | types/wlr_server_decoration.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/types/wlr_server_decoration.c b/types/wlr_server_decoration.c index 425230ec..3cf19c2f 100644 --- a/types/wlr_server_decoration.c +++ b/types/wlr_server_decoration.c @@ -24,7 +24,7 @@ static void server_decoration_handle_request_mode(struct wl_client *client, struct wl_resource *resource, uint32_t mode) { struct wlr_server_decoration *decoration = decoration_from_resource(resource); - if (decoration->mode == mode) { + if (decoration == NULL || decoration->mode == mode) { return; } decoration->mode = mode; |