aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBrian J. Tarricone <brian@tarricone.org>2023-09-27 23:54:51 -0700
committerBrian J. Tarricone <brian@tarricone.org>2023-09-27 23:54:51 -0700
commiteacb4cf6d290ba197be1ce6070cba172213e1fc4 (patch)
treee730b3cb58b67d3397664c25864dd03d1688beaf
parent1a731596c5bcd252d8796cacb59af8b20ceb914f (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.c2
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;