[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] console: avoid buffer overflow in guest_console_write()


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Jürgen Groß <jgross@xxxxxxxx>, Julien Grall <julien@xxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 29 Nov 2019 13:57:03 +0000
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=andrew.cooper3@xxxxxxxxxx; spf=Pass smtp.mailfrom=Andrew.Cooper3@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Autocrypt: addr=andrew.cooper3@xxxxxxxxxx; prefer-encrypt=mutual; keydata= mQINBFLhNn8BEADVhE+Hb8i0GV6mihnnr/uiQQdPF8kUoFzCOPXkf7jQ5sLYeJa0cQi6Penp VtiFYznTairnVsN5J+ujSTIb+OlMSJUWV4opS7WVNnxHbFTPYZVQ3erv7NKc2iVizCRZ2Kxn srM1oPXWRic8BIAdYOKOloF2300SL/bIpeD+x7h3w9B/qez7nOin5NzkxgFoaUeIal12pXSR Q354FKFoy6Vh96gc4VRqte3jw8mPuJQpfws+Pb+swvSf/i1q1+1I4jsRQQh2m6OTADHIqg2E ofTYAEh7R5HfPx0EXoEDMdRjOeKn8+vvkAwhviWXTHlG3R1QkbE5M/oywnZ83udJmi+lxjJ5 YhQ5IzomvJ16H0Bq+TLyVLO/VRksp1VR9HxCzItLNCS8PdpYYz5TC204ViycobYU65WMpzWe LFAGn8jSS25XIpqv0Y9k87dLbctKKA14Ifw2kq5OIVu2FuX+3i446JOa2vpCI9GcjCzi3oHV e00bzYiHMIl0FICrNJU0Kjho8pdo0m2uxkn6SYEpogAy9pnatUlO+erL4LqFUO7GXSdBRbw5 gNt25XTLdSFuZtMxkY3tq8MFss5QnjhehCVPEpE6y9ZjI4XB8ad1G4oBHVGK5LMsvg22PfMJ ISWFSHoF/B5+lHkCKWkFxZ0gZn33ju5n6/FOdEx4B8cMJt+cWwARAQABtClBbmRyZXcgQ29v cGVyIDxhbmRyZXcuY29vcGVyM0BjaXRyaXguY29tPokCOgQTAQgAJAIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAUCWKD95wIZAQAKCRBlw/kGpdefoHbdD/9AIoR3k6fKl+RFiFpyAhvO 59ttDFI7nIAnlYngev2XUR3acFElJATHSDO0ju+hqWqAb8kVijXLops0gOfqt3VPZq9cuHlh IMDquatGLzAadfFx2eQYIYT+FYuMoPZy/aTUazmJIDVxP7L383grjIkn+7tAv+qeDfE+txL4 SAm1UHNvmdfgL2/lcmL3xRh7sub3nJilM93RWX1Pe5LBSDXO45uzCGEdst6uSlzYR/MEr+5Z JQQ32JV64zwvf/aKaagSQSQMYNX9JFgfZ3TKWC1KJQbX5ssoX/5hNLqxMcZV3TN7kU8I3kjK mPec9+1nECOjjJSO/h4P0sBZyIUGfguwzhEeGf4sMCuSEM4xjCnwiBwftR17sr0spYcOpqET ZGcAmyYcNjy6CYadNCnfR40vhhWuCfNCBzWnUW0lFoo12wb0YnzoOLjvfD6OL3JjIUJNOmJy RCsJ5IA/Iz33RhSVRmROu+TztwuThClw63g7+hoyewv7BemKyuU6FTVhjjW+XUWmS/FzknSi dAG+insr0746cTPpSkGl3KAXeWDGJzve7/SBBfyznWCMGaf8E2P1oOdIZRxHgWj0zNr1+ooF /PzgLPiCI4OMUttTlEKChgbUTQ+5o0P080JojqfXwbPAyumbaYcQNiH1/xYbJdOFSiBv9rpt TQTBLzDKXok86LkCDQRS4TZ/ARAAkgqudHsp+hd82UVkvgnlqZjzz2vyrYfz7bkPtXaGb9H4 Rfo7mQsEQavEBdWWjbga6eMnDqtu+FC+qeTGYebToxEyp2lKDSoAsvt8w82tIlP/EbmRbDVn 7bhjBlfRcFjVYw8uVDPptT0TV47vpoCVkTwcyb6OltJrvg/QzV9f07DJswuda1JH3/qvYu0p vjPnYvCq4NsqY2XSdAJ02HrdYPFtNyPEntu1n1KK+gJrstjtw7KsZ4ygXYrsm/oCBiVW/OgU g/XIlGErkrxe4vQvJyVwg6YH653YTX5hLLUEL1NS4TCo47RP+wi6y+TnuAL36UtK/uFyEuPy wwrDVcC4cIFhYSfsO0BumEI65yu7a8aHbGfq2lW251UcoU48Z27ZUUZd2Dr6O/n8poQHbaTd 6bJJSjzGGHZVbRP9UQ3lkmkmc0+XCHmj5WhwNNYjgbbmML7y0fsJT5RgvefAIFfHBg7fTY/i kBEimoUsTEQz+N4hbKwo1hULfVxDJStE4sbPhjbsPCrlXf6W9CxSyQ0qmZ2bXsLQYRj2xqd1 bpA+1o1j2N4/au1R/uSiUFjewJdT/LX1EklKDcQwpk06Af/N7VZtSfEJeRV04unbsKVXWZAk uAJyDDKN99ziC0Wz5kcPyVD1HNf8bgaqGDzrv3TfYjwqayRFcMf7xJaL9xXedMcAEQEAAYkC HwQYAQgACQUCUuE2fwIbDAAKCRBlw/kGpdefoG4XEACD1Qf/er8EA7g23HMxYWd3FXHThrVQ HgiGdk5Yh632vjOm9L4sd/GCEACVQKjsu98e8o3ysitFlznEns5EAAXEbITrgKWXDDUWGYxd pnjj2u+GkVdsOAGk0kxczX6s+VRBhpbBI2PWnOsRJgU2n10PZ3mZD4Xu9kU2IXYmuW+e5KCA vTArRUdCrAtIa1k01sPipPPw6dfxx2e5asy21YOytzxuWFfJTGnVxZZSCyLUO83sh6OZhJkk b9rxL9wPmpN/t2IPaEKoAc0FTQZS36wAMOXkBh24PQ9gaLJvfPKpNzGD8XWR5HHF0NLIJhgg 4ZlEXQ2fVp3XrtocHqhu4UZR4koCijgB8sB7Tb0GCpwK+C4UePdFLfhKyRdSXuvY3AHJd4CP 4JzW0Bzq/WXY3XMOzUTYApGQpnUpdOmuQSfpV9MQO+/jo7r6yPbxT7CwRS5dcQPzUiuHLK9i nvjREdh84qycnx0/6dDroYhp0DFv4udxuAvt1h4wGwTPRQZerSm4xaYegEFusyhbZrI0U9tJ B8WrhBLXDiYlyJT6zOV2yZFuW47VrLsjYnHwn27hmxTC/7tvG3euCklmkn9Sl9IAKFu29RSo d5bD8kMSCYsTqtTfT6W4A3qHGvIDta3ptLYpIAOD2sY3GYq2nf3Bbzx81wZK14JdDDHUX2Rs 6+ahAA==
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, KonradWilk <konrad.wilk@xxxxxxxxxx>, Ilja Van Sprundel <ivansprundel@xxxxxxxxxxxx>, GeorgeDunlap <George.Dunlap@xxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 29 Nov 2019 13:57:16 +0000
  • Ironport-sdr: 8R2eoTc2/N3qOkNXFidH2pS9HRbSWrta98mhZewABe3XmETnR696d7dXjdgha3+rkmsiKruqIG 9YQx4LfVY3jXrs7pChIKo62G4pEXI9JvF2367bZBCtRv9OPV/aAgPBdxm6/4l4wQ8/heMQzLqy I4aKEtNJjEd2RgK5LGa7p7ty3TVPHVYkUu8YhPklIyy5RmY9troshdm9zmy0EMDglXT3a1ur4o OWGs1ZiavM/HHaK9s2nxMBTIAOy2yLOILYq/Gqcv24C8/YkiuKHvL6+lsuf2uWooyChBNtEoCt hMA=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 29/11/2019 13:55, Jan Beulich wrote:
> On 29.11.2019 14:37, Jürgen Groß wrote:
>> On 29.11.19 14:26, Jan Beulich wrote:
>>> On 29.11.2019 13:37, Andrew Cooper wrote:
>>>> On 29/11/2019 12:19, Jan Beulich wrote:
>>>>> On 29.11.2019 13:15, Andrew Cooper wrote:
>>>>>> On 29/11/2019 12:13, Jan Beulich wrote:
>>>>>>> On 29.11.2019 13:01, Ian Jackson wrote:
>>>>>>>> Jan Beulich writes ("Re: [PATCH] console: avoid buffer overflow in 
>>>>>>>> guest_console_write()"):
>>>>>>>>> On 29.11.2019 11:22, Andrew Cooper wrote:
>>>>>>>>>> Is sizeof(array[0]) always 0, or is this just a GCC-ism ?  Godbolt
>>>>>>>>>> suggests is 0 on all compiler we support.
>>>>>>>>>>
>>>>>>>>>> Either way, isn't the more common idiom + 0ul ?  Personally, I feel 
>>>>>>>>>> that
>>>>>>>>>> is clearer to follow.
>>>>>>>>> I decided against + 0ul or alike because in principle size_t
>>>>>>>>> and unsigned long are different types. In particular 32-bit
>>>>>>>>> x86 gcc uses unsigned int for size_t, and hence min()'s
>>>>>>>>> type safety check would cause the build to fail there. The
>>>>>>>>> same risk obviously exists for any 32-bit arch (e.g. Arm32,
>>>>>>>>> but I haven't checked what type it actually uses).
>>>>>>>> I don't know what i wrong with
>>>>>>>>     (size_t)0
>>>>>>>> which is shorter, even !
>>>>>>> True. Yet it contains a cast, no matter how risk-free it may be
>>>>>>> in this case. With a cast, I could as well have written (yet
>>>>>>> shorter) (size_t)count.
>>>>>> Given that min() has a very strict typecheck, I think we should permit
>>>>>> any use of an explicit cast in a single operand, because it *is* safer
>>>>>> than switching to the min_t() route to make things compile.
>>>>> Well, I can switch to (size_t)count if this is liked better
>>>>> overall.
>>>> Personally, I'd prefer this option most of all.
>>> Okay, I've switched to this, but while doing so I started wondering
>>> why we'd then not use
>>>
>>>          kcount = min(count, (unsigned int)sizeof(kbuf) - 1);
>>>
>>> which is an (often slightly cheaper) 32-bit operation (and which
>>> is what I had actually started from).
>> While modifying guest_console_write(), would you mind writing a '\0'
>> to kbuf[kcount]? There is a "conring_puts(kbuf);" later in this
>> function which would like a 0 terminated string as input.
> That's not the right change for this problem, I think. Now that
> we support embedded nul characters, a count should be passed
> instead. Julien?
>
> I also wouldn't want to merge this into this patch; I'm happy to
> send a separate one.

I agree.  Lets fix the concrete stack corruption issue separately from
the concern over NUL-correctness (which was the purpose of the patch
which introduced this vulnerability to start with).

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.