PostgreSQL CVE-2016-5423 BUG

背景

PostgreSQL 的一个BUG，存在于9.5.3, 9.4.8, 9.3.13, 9.2.17, 9.1.22及以下版本。

在使用嵌套CASE WHEN语句时，如果嵌套子句中有检测条件为空时，会导致判断不准确。

如果内外检测值的类型不同，甚至有可能导致数据库crash。

https://www.postgresql.org/docs/9.5/static/release-9-5-4.html

Fix possible mis-evaluation of nested CASE-WHEN expressions (Heikki Linnakangas, Michael Paquier, Tom Lane)  
  
A CASE expression appearing within the test value subexpression of another CASE could become confused about whether its own test value was null or not.   
  
Also, inlining of a SQL function implementing the equality operator used by a CASE expression could result in passing the wrong test value to functions called within a CASE expression in the SQL function's body.   
  
If the test values were of different data types, a crash might result;   
  
moreover such situations could be abused to allow disclosure of portions of server memory.   
(CVE-2016-5423)  

补丁

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=f0c7b789ab12fbc8248b671c7882dd96ac932ef4

Fix two errors with nested CASE/WHEN constructs.  
  
ExecEvalCase() tried to save a cycle or two by passing &econtext->caseValue_isNull as the isNull argument to its sub-evaluation of the CASE value expression.    
  
If that subexpression itself contained a CASE,   
then *isNull was an alias for econtext->caseValue_isNull within the recursive call of ExecEvalCase(),   
leading to confusion about whether the inner call's caseValue was null or not.    
  
In the worst case this could lead to a core dump due to dereferencing a null pointer.    
  
Fix by not assigning to the global variable until control comes back from the subexpression.  
  
Also, avoid using the passed-in isNull pointer transiently for evaluation of WHEN expressions.    
  
(Either one of these changes would have been sufficient to fix the known misbehavior,   
but it's clear now that each of these choices was in itself dangerous coding practice and best avoided.  
There do not seem to be any similar hazards elsewhere in execQual.c.)  
  
  
Also, it was possible for inlining of a SQL function that implements the equality operator used for a CASE comparison to result in one CASE expression's CaseTestExpr node being inserted inside another CASE expression.    
  
This would certainly result in wrong answers since the improperly nested CaseTestExpr would be caused to return the inner CASE's comparison value not the outer's.    
  
If the CASE values were of different data types, a crash might result;   
  
moreover such situations could be abused to allow disclosure of portions of server memory.    
  
To fix, teach inline_function to check for "bare" CaseTestExpr nodes in the arguments of a function to be inlined, and avoid inlining if there are any.  
  
Heikki Linnakangas, Michael Paquier, Tom Lane  
  
Report: https://github.com/greenplum-db/gpdb/pull/327  
Report: <4DDCEEB8.50602@enterprisedb.com>  
Security: CVE-2016-5423  

讨论见
https://www.postgresql.org/message-id/flat/4DDCEEB8.50602%40enterprisedb.com#4DDCEEB8.50602@enterprisedb.com

test case

-- Nested CASE expressions  
--  
-- This test exercises a bug caused by aliasing econtext->caseValue_isNull  
-- with the isNull argument of the inner CASE's ExecEvalCase() call.  After  
-- evaluating the vol(null) expression in the inner CASE's second WHEN-clause,  
-- the isNull flag for the case test value incorrectly became true, causing  
-- the third WHEN-clause not to match.  The volatile function calls are needed  
-- to prevent constant-folding in the planner, which would hide the bug.  
CREATE FUNCTION vol(text) returns text as  
  'begin return $1; end' language plpgsql volatile;  
SELECT CASE  
  (CASE vol('bar')  
    WHEN 'foo' THEN 'it was foo!'  
    WHEN vol(null) THEN 'null input'  -- 嵌套case when子句的equal判断中存在null值时，导致整个case 判断错误。    
    WHEN 'bar' THEN 'it was bar!' END  
  )  
  WHEN 'it was foo!' THEN 'foo recognized'  
  WHEN 'it was bar!' THEN 'bar recognized'  
  ELSE 'unrecognized' END;  

修复前结果

     case       
--------------  
 unrecognized  
(1 row)  

修复后结果

      case        
----------------  
 bar recognized  
(1 row)  

测试CASE 2

-- In this case, we can't inline the SQL function without confusing things.  
CREATE DOMAIN foodomain AS text;  
CREATE FUNCTION volfoo(text) returns foodomain as  
  'begin return $1::foodomain; end' language plpgsql volatile;  
CREATE FUNCTION inline_eq(foodomain, foodomain) returns boolean as  
  'SELECT CASE $2::text WHEN $1::text THEN true ELSE false END' language sql;  
CREATE OPERATOR = (procedure = inline_eq,  
                   leftarg = foodomain, rightarg = foodomain);  
SELECT CASE volfoo('bar') -- function被case用作等于判断时，通过function传递的参数值无法正确的传达给function内的case when判断。      
WHEN 'foo'::foodomain THEN 'is foo' ELSE 'is not foo' END;  

修复前结果

  case    
--------  
 is foo  
(1 row)  

修复后结果

    case      
------------  
 is not foo  
(1 row)  

digoal’s 大量PostgreSQL文章入口