NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/13082
The following reply was made to PR lib/13082; it has been noted by GNATS.
From: Thorsten Brehm <tbrehm%dspace.de@localhost>
To: "gnats-bugs%gnats.netbsd.org@localhost"
<gnats-bugs%gnats.netbsd.org@localhost>
Cc: "christos%zoulas.com@localhost" <christos%zoulas.com@localhost>
Subject: Re: lib/13082
Date: Tue, 26 Feb 2013 09:16:50 +0000
--_000_C8EE0F1FA402474893651B07DA446721EDC3BACEExchange2010dsp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
This bug should be raised to "critical", since it causes sporadic segfaults=
. The incorrect memcpy source location has already been described in the re=
port.
But moreover, the memory location &raddr->buf only guarantees 4 bytes (or 8=
bytes on 64 bit systems) to be accessible, while raddr->len is larger than=
4 (or 8). When &raddr->buf is located at the end of an accessible memory s=
egment, then memcpy(...,&raddr->buf, raddr->len) results in a memory violat=
ion (apart from not copying the right data). I've seen this crash regularly=
, obviously depending on the memory layout of the application.
The following patch fixes the segfault and also the second issue mentioned =
by Christos, which I can also confirm:
diff -wru trunk/src/lib/libc/rpc/clnt_vc.c new/src/lib/libc/rpc/clnt_vc.c
--- trunk/src/lib/libc/rpc/clnt_vc.c
+++ new/src/lib/libc/rpc/clnt_vc.c
@@ -263,8 +263,8 @@
ct->ct_addr.buf =3D malloc((size_t)raddr->maxlen);
if (ct->ct_addr.buf =3D=3D NULL)
goto fooy;
- memcpy(ct->ct_addr.buf, &raddr->buf, (size_t)raddr->len);
- ct->ct_addr.len =3D raddr->maxlen;
+ memcpy(ct->ct_addr.buf, raddr->buf, (size_t)raddr->len);
+ ct->ct_addr.len =3D raddr->len;
ct->ct_addr.maxlen =3D raddr->maxlen;
/*
I've debugged, fixed and tested this locally - before seeing the issue and =
patch has already been known for more than 11 years. So *please* let's fix =
this now ;-).
Thorsten
--_000_C8EE0F1FA402474893651B07DA446721EDC3BACEExchange2010dsp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"; xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Vorformatiert Zchn";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.E-MailFormatvorlage17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.HTMLVorformatiertZchn
{mso-style-name:"HTML Vorformatiert Zchn";
mso-style-priority:99;
mso-style-link:"HTML Vorformatiert";
font-family:"Courier New";
mso-fareast-language:DE;}
.MsoChpDefault
{mso-style-type:export-only;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"DE" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">This bug should be raised to &#=
8220;critical”, since it causes sporadic segfaults. The incorrect mem=
cpy source location has already been described in the report.<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">But moreover, the memory locati=
on &raddr->buf only guarantees 4 bytes (or 8 bytes on 64 bit systems=
) to be accessible, while raddr->len is larger than 4 (or 8). When &=
raddr->buf is located at the end of an accessible
memory segment, then memcpy(…,&raddr->buf, raddr->len) res=
ults in a memory violation (apart from not copying the right data). I’=
;ve seen this crash regularly, obviously depending on the memory layout of =
the application.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">The following patch fixes the s=
egfault and also the second issue mentioned by Christos, which I can also c=
onfirm:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">diff -wru trunk/src/lib/libc/rp=
c/clnt_vc.c new/src/lib/libc/rpc/clnt_vc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">--- trunk/src/lib/libc/rpc/clnt=
_vc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">+++ new/src/lib/lib=
c/rpc/clnt_vc.c<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">@@ -263,8 +263,8 @@<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"> &=
nbsp; ct->ct_addr.buf =
=3D malloc((size_t)raddr->maxlen);<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"> &=
nbsp; if (ct->ct_addr.bu=
f =3D=3D NULL)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"> &=
nbsp; &nbs=
p; goto f=
ooy;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">- =
memcpy(ct->ct_addr.buf,=
&raddr->buf, (size_t)raddr->len);<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">- =
ct->ct_addr.len =3D rad=
dr->maxlen;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">+ &n=
bsp; memcpy(ct->ct_addr.buf, r=
addr->buf, (size_t)raddr->len);<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">+ &n=
bsp; ct->ct_addr.len =3D raddr=
->len;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"> &=
nbsp; ct->ct_addr.maxlen=
=3D raddr->maxlen;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"> &=
nbsp; /*<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I’ve debugged, fixed and =
tested this locally – before seeing the issue and patch has already b=
een known for more than 11 years. So *<b>please</b>* let’s fix this n=
ow ;-).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Thorsten<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
</div>
</body>
</html>
--_000_C8EE0F1FA402474893651B07DA446721EDC3BACEExchange2010dsp_--
Home |
Main Index |
Thread Index |
Old Index