[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A possible pointer_overflow in xen-4.13
 
- To: Rroach <2284696125@xxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
 
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
 
- Date: Sat, 26 Jun 2021 14:50:37 +0100
 
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
 
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O1RqFWzu0I3vAXD4pa7U6+yCgAxkwwoDMeZNDEYeE/s=; b=QKlQlbHBDZkd+TJ+2NU6t3SXAGAfWpNZVSPTuNsN/3Ek4MsuT3iAj+C9biD1+gQcgjgm2gwM9p7GHzqeU5XYkaKE/HB0/QpZblI7pRQVy+XdcBtN1PhZIUvYR5Sn0maPO39VbUIs/W0Hp6tPbGtyFHW+y7cT0M8zunpiSozh7PmrmyxgaAXlvZT3aBFgjj9ziqFG8veihYBEMgE6jXaW72qjJhoVhDk9nEhjAWQQLMVq76G3coOLrExTqVUjibd8msDKD+uEOk4MBaWo9dJHpwTgB+i5wfd6vlnKo89xkEHtNdNETH+dXg1UirEkVGi1V+OhEFgobxc3emtsPqUp1Q==
 
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KhS8DXJVbzNnR6JHOeGQNM9f/1os91/ubrQqOlcREl0NsMexi7cLxKZsznvDkGBXsxprAncDvs1EZtj8IHuN0Zg55WR5KuxCMKjF+5If1EA41RVHW89h+fcvYdAHeRiD6BxZ7RJCvNEBr3Kwmp/InEKV01APsdMQ5yrhqMAwFt9r1/vsN10U/FgI1HR5fGKHUoAadAWqXcDEiAGETZ2ak4+M/Opa1x/mloqKcWznvCS3OP1mLCCkYtW5hULYIcILo+dahuQJlRsgeAQRrx+JoI9aHy8sygOLh9NkuFhF4bbWRkuFQwsSD/qu+NlwVw4R7U6HP8r4nTqbotFbwej80A==
 
- Authentication-results: esa3.hc3370-68.iphmx.com; dkim=hardfail (body hash did not verify [final]) header.i=@citrix.onmicrosoft.com
 
- Delivery-date: Sat, 26 Jun 2021 13:51:06 +0000
 
- Ironport-hdrordr: A9a23:tkNaQ641vy9e9R1oEAPXwTiBI+orL9Y04lQ7vn2ZFiY6TiXIra +TdaoguSMc6AxwZJhSo6H9BEDgewKgyXcR2+gs1NiZLXHbUQeTXeZfBM7Zskfd8k7Fh55gPM VbAtFD4bTLZDAQ56uKg3jbYqQdKZu8gcSVbI/lvgZQpGpRGsddBmlCe2Om+wFNNXJ77c1TLu vj2iMLnUvsRV0nKuCAQlUVVenKoNPG0LrgfB49HhYirC2Dlymh5rLWGwWRmk52aUIB/Z4StU z+1yDp7KSqtP+2jjfaym/o9pxT3P/s0MFKCsCggtUcbh/slgGrToJ8XKDqhkF4nMifrHIR1P XcqRYpOMp+r1nLeHuunBfr0w78lB4z9n7L0zaj8DveiP28YAh/J9tKhIpffBecwVEnpstA3K VC2H/cn4ZLDCnHgD/267HzJlBXf3KP0DgfeNMo/jliudN0Us4UkWVfxjIaLH44JlO41Gh9e9 MeS/01jZ1tACCnh3OwhBgm/DXjZAV0Iv68eDl3hiWi6UkeoJlI9Tps+CUhpAZ2yHsccegO2w 2WCNUjqFlxJvVmG56VU91xPvdfTFa9GC7xDA==
 
- Ironport-sdr: ghlMmVxhq9iozOb+eY8NH6Roh2XEly7Bfm9JtWJQuZrXpTlqu3LydqfZ0YrWNBWc5xTZYSbdB/ 6hlKmsMC1rqPb+LoKJqX+DCjrtS3VQ7WGqhyUH9ZdTBBwbqLZ2/JAEvUPQlwJhQAZoOjz40Kzj SkUrtLSr7TrudY9nADdhaxxzqYaa23FKwslGIMbHMtuL8csIIpDP9TSuZuWLgIBhclYkJQZox1 zQAAGS1TP2CYQTnn1FyqdjEv8+FXbmWwNvIvwk5H+8Vv1Cwx1epIucmwuYObITjtpWgVHs6BIL jvk=
 
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
 
 
 
  
    On 26/06/2021 14:29, Rroach wrote: 
     
    
      
      
          Hi, I compile Xen-4.13 with CONFIG_UBSAN, and try test
            it. However, during testing, xl dmesg got the output as
            shown below. 
           
           
          It seems that there is a potential pointer overflow
            within arch/x86/pv/emul-priv-op.c:131 where xen try to
            execute instruction ''' APPEND_CALL(save_guest_gprs)
            '''£¬where APPEND_CALL try to add an offset on *p without
            proper checking. 
           
           
          I compiled xen-4.13 by clang-9, with following
            instructions: ''' export CONFIG_UBSAN=y ''' && '''
            make clang=y debug=y ''' . Do you have any idea what going
            on here? 
         
     
     
    You say Xen 4.13, but APPEND_CALL() doesn't exist
      there.  I added it in 4.14 when I rewrote this mess to be
      compatible with CET by not using a ROP gadget.  Your backtrace
      says 4.15 unstable which means its an old staging build (not that
      that is going to have any effect on this specific issue). 
       
      The fact that it continued executing correctly means the
      calculation did the right thing, whether or not UBSAN was happy. 
      The displacement will end up negative as the stub we're writing is
      numerically higher than {load,save}_guest_gprs(), which I guess
      means that f - stub_va will underflow. 
       
      I'm very confused as to why UBSAN reports against
      save_guest_gprs() considering that load_guest_gprs() when through
      the exact same logic a few instructions earlier. 
       
      Either way, does this make the problem go away? 
       
      diff --git a/xen/arch/x86/pv/emul-priv-op.c
      b/xen/arch/x86/pv/emul-priv-op.c 
      index 11467a1e3a..be41bced76 100644 
      --- a/xen/arch/x86/pv/emul-priv-op.c 
      +++ b/xen/arch/x86/pv/emul-priv-op.c 
      @@ -98,7 +98,7 @@ static io_emul_stub_t *io_emul_stub_setup(struct
      priv_op_ctxt *ctxt, u8 opcode, 
       #define APPEND_BUFF(b) ({ memcpy(p, b, sizeof(b)); p +=
      sizeof(b); }) 
       #define
      APPEND_CALL(f)                                                  \ 
          
      ({                                                                 
      \ 
      -        long disp = (long)(f) - (stub_va + p -
      ctxt->io_emul_stub + 5); \ 
      +        long disp = (long)(f) - (long)(stub_va + p -
      ctxt->io_emul_stub + 5); \ 
               BUG_ON((int32_t)disp !=
      disp);                                  \ 
               *p++ =
      0xe8;                                                    \ 
               *(int32_t *)p = disp; p +=
      4;                                   \ 
       
      ~Andrew 
  
 
    
     |