Skip to content
  • Karthik Kamath's avatar
    371cb91d
    BUG#24595581: NULL POINTER DEREFERENCE WHILE USING LONGTEXT · 371cb91d
    Karthik Kamath authored
                  FUNCTION IN SUBQUERY
    
    ANALYSIS:
    =========
    Server runs into null pointer dereferencing when a
    deterministic function returning longtext is used in a
    subquery.
    
    Item::const_item() is 'true' for all items having no table
    reference bits set. So it is 'true' for subqueries and
    deterministic functions that do not reference any tables.
    However, we cannot always consider items to be constant
    based on the referenced table bits. In this scenario, a
    deterministic function is considered a const item. Hence the
    resolver tries to evaluate the function in the preparation
    phase. At this phase, the query tables are open but not
    locked. After the evaluation, all the tables in the outer
    query block are closed. Later during the execution phase,
    when we try to lock the query tables, the TABLE object will
    be unused, thus leading to a null pointer dereference.
    
    FIX:
    ====
    We are overriding the function 'fix_after_pullout' in the
    'Item_func_sp' class where we are not considering
    deterministic functions as const items based on their table
    reference, thus preventing the resolver from evaluating
    the function in the preparation phase.
    371cb91d
    BUG#24595581: NULL POINTER DEREFERENCE WHILE USING LONGTEXT
    Karthik Kamath authored
                  FUNCTION IN SUBQUERY
    
    ANALYSIS:
    =========
    Server runs into null pointer dereferencing when a
    deterministic function returning longtext is used in a
    subquery.
    
    Item::const_item() is 'true' for all items having no table
    reference bits set. So it is 'true' for subqueries and
    deterministic functions that do not reference any tables.
    However, we cannot always consider items to be constant
    based on the referenced table bits. In this scenario, a
    deterministic function is considered a const item. Hence the
    resolver tries to evaluate the function in the preparation
    phase. At this phase, the query tables are open but not
    locked. After the evaluation, all the tables in the outer
    query block are closed. Later during the execution phase,
    when we try to lock the query tables, the TABLE object will
    be unused, thus leading to a null pointer dereference.
    
    FIX:
    ====
    We are overriding the function 'fix_after_pullout' in the
    'Item_func_sp' class where we are not considering
    deterministic functions as const items based on their table
    reference, thus preventing the resolver from evaluating
    the function in the preparation phase.
Loading