zmike pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=91fe39af902054845c4dca10dcffa7cd0d476066

commit 91fe39af902054845c4dca10dcffa7cd0d476066
Author: Marcel Hollerbach <[email protected]>
Date:   Tue Apr 14 11:29:50 2020 -0400

    ecore_evas_x: add safety check for data in converter
    
    Summary:
    since the existance of seleciton manager, the converter callbacks from
    ecore_x are expecting custom struct pointers. However, enlightenment
    never updated to use the elm dnd API for client side usages. Which
    results in the fact that sometimes, when a client sents Notify, and
    e_dnd is active, that this converter is executed with the wrong data.
    
    With this commit the data passed in is ensured to have the correct magic
    number. The proper solution for this would either be registering the
    correct converters in enlightenment, or update to elm_drag. However,
    since the continues cried river over the last 5 days has raised enough
    hydro power to add these changes. This leaves us with just one question:
    How was it possible to generate so many messages about a problem that
    can be solved in a fraction of charaters that have been written?
    
    fixes <a-issue-that-was-never-created>
    Depends on D11700
    
    Reviewers: zmike, stefan_schmidt, raster
    
    Reviewed By: zmike
    
    Subscribers: cedric, #reviewers, #committers
    
    Tags: #efl
    
    Differential Revision: https://phab.enlightenment.org/D11701
---
 src/modules/ecore_evas/engines/x/ecore_evas_x.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/src/modules/ecore_evas/engines/x/ecore_evas_x.c 
b/src/modules/ecore_evas/engines/x/ecore_evas_x.c
index a107f66a6d..1a0ae1f4b8 100644
--- a/src/modules/ecore_evas/engines/x/ecore_evas_x.c
+++ b/src/modules/ecore_evas/engines/x/ecore_evas_x.c
@@ -49,6 +49,8 @@
 # endif
 #endif /* ! _WIN32 */
 
+#define ECORE_EVAS_X11_SELECTION 0x7F
+
 #define EDBG(...)                                                       \
   EINA_LOG(_ecore_evas_log_dom, EINA_LOG_LEVEL_DBG + 1, __VA_ARGS__);
 
@@ -75,6 +77,7 @@ static Eina_Bool wm_exists;
 typedef struct _Ecore_Evas_Engine_Data_X11 Ecore_Evas_Engine_Data_X11;
 
 typedef struct {
+   EINA_MAGIC;
    Ecore_Evas_Selection_Callbacks callbacks;
    Ecore_Evas_Selection_Buffer buffer;
    Ecore_Evas *ee;
@@ -4053,6 +4056,11 @@ _eina_content_converter(char *target, void *data, int 
size EINA_UNUSED, void **d
 {
    Ecore_Evas_X11_Selection_Data *sdata = data;
    Eina_Bool ret = EINA_FALSE;;
+
+   if (size != sizeof(Ecore_Evas_X11_Selection_Data)) return EINA_FALSE;
+
+   if (!EINA_MAGIC_CHECK(sdata, ECORE_EVAS_X11_SELECTION)) return EINA_FALSE;
+
    if (eina_streq(target, "TARGETS") || eina_streq(target, "ATOM"))
      {
         //list all available types that we have currently
@@ -4327,6 +4335,7 @@ _ecore_evas_x_selection_window_init(Ecore_Evas *ee)
         ecore_x_fixes_window_selection_notification_request(ee->prop.window, 
ecore_evas_selection_to_atom[i]);
         edata->selection_data[i].ee = ee;
         edata->selection_data[i].buffer = i;
+        EINA_MAGIC_SET(&edata->selection_data[i], ECORE_EVAS_X11_SELECTION);
      }
    ecore_x_dnd_aware_set(ee->prop.window, EINA_TRUE);
    edata->init_job = ecore_job_add(_deliver_selection_changed, ee);

-- 


Reply via email to