From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 62F1D3858C66 for ; Wed, 19 Jul 2023 11:00:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 62F1D3858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 36JAuYrB031504; Wed, 19 Jul 2023 11:00:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=gRAfQ/QJcS1lCdgA+IcMUjk92UqY1gHAsYr5p2JmI4k=; b=O+8YQGFm3FsbQfnUt1vTvj9bw14v1hT1kAfmmkp5u2vN7K5mbOmZ+K8z9spt/dRdYBP7 HBtwCGm7SIRdK05ez6cD0aDSfJoLJ47tFmaWKFaiiuPSujmsxGMgShZezy/GdsJo0Op8 gD7AraxsL02YkBTBYPPMkC3oW/MIwvePVtE1RddzDE2baW/d8v7S5GrAnDaZwTIGI+3w TcP8Vxf/hs6hx6fNePKQnXfIj/7giopKk5660ezbH2ZuXcyI0IdctyB1xr3zBKkU1f34 Jw0MyGnGxHd0yB8L5ROWEZ0FwQzDun22UIWc27E84xkVd1CwqYg8tudyDWutwzp0lbw+ LA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rxeh002f2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2023 11:00:40 +0000 Received: from m0360072.ppops.net (m0360072.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 36JAum0T032090; Wed, 19 Jul 2023 11:00:39 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3rxeh002et-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2023 11:00:39 +0000 Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 36J98Kth004183; Wed, 19 Jul 2023 11:00:39 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 3rv8g120cd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2023 11:00:38 +0000 Received: from smtpav02.fra02v.mail.ibm.com (smtpav02.fra02v.mail.ibm.com [10.20.54.101]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 36JB0bRG58917252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Jul 2023 11:00:37 GMT Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 37B7E20040; Wed, 19 Jul 2023 11:00:37 +0000 (GMT) Received: from smtpav02.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 175B22004E; Wed, 19 Jul 2023 11:00:37 +0000 (GMT) Received: from [9.155.200.166] (unknown [9.155.200.166]) by smtpav02.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 19 Jul 2023 11:00:37 +0000 (GMT) Message-ID: Subject: Re: [PATCH] gdb: Fix "target file /proc/.../cmdline contained unexpected null characters" From: Ilya Leoshkevich To: Bruno Larsen , Tom Tromey Cc: gdb-patches@sourceware.org Date: Wed, 19 Jul 2023 13:00:36 +0200 In-Reply-To: References: <20230621231425.3972673-1-iii@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: jtqtNaJqYouWJHq4btd6iSByRzmXO4Nn X-Proofpoint-GUID: gBSj2s9nH4mXYwcEW4WDa3DYhbdPjJWr X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.957,Hydra:6.0.591,FMLib:17.11.176.26 definitions=2023-07-19_06,2023-07-19_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 suspectscore=0 clxscore=1011 mlxlogscore=999 lowpriorityscore=0 bulkscore=0 mlxscore=0 priorityscore=1501 spamscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2307190095 X-Spam-Status: No, score=-10.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 2023-07-18 at 15:03 +0200, Bruno Larsen wrote: > On 22/06/2023 01:14, Ilya Leoshkevich via Gdb-patches wrote: > > cmdline is read with target_fileio_read_stralloc(), which warns on > > seeing null characters.=C2=A0 However, it's perfectly valid for cmdline > > to > > contain \0s, so switch to target_fileio_read_alloc(). >=20 > Hi! Thanks for working on this. Thanks for the review! >=20 > =C2=A0From what I understand, GDB commit messages should be written so > that=20 > they make sense even if you don't read the title, so having a > slightly=20 > more descriptive message would be nice. Will do. > > --- > > =C2=A0 gdb/linux-tdep.c | 13 ++++++++++--- > > =C2=A0 1 file changed, 10 insertions(+), 3 deletions(-) > >=20 > > diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c > > index b5eee5e108c..96cbe8e5520 100644 > > --- a/gdb/linux-tdep.c > > +++ b/gdb/linux-tdep.c > > @@ -1902,15 +1902,22 @@ linux_fill_prpsinfo (struct > > elf_internal_linux_prpsinfo *p) > > =C2=A0=C2=A0=C2=A0 pid =3D inferior_ptid.pid (); > > =C2=A0=C2=A0=C2=A0 xsnprintf (filename, sizeof (filename), "/proc/%d/cm= dline", > > (int) pid); > > =C2=A0=C2=A0=C2=A0 /* The full name of the program which generated the = corefile.=C2=A0 > > */ > > -=C2=A0 gdb::unique_xmalloc_ptr fname > > -=C2=A0=C2=A0=C2=A0 =3D target_fileio_read_stralloc (NULL, filename); > > +=C2=A0 gdb_byte *buf =3D NULL; > > +=C2=A0 size_t buf_len =3D target_fileio_read_alloc (NULL, filename, > > &buf); > > +=C2=A0 gdb::unique_xmalloc_ptr fname ((char *)buf); > > =C2=A0=20 >=20 > Looking at the code on linux_info_proc, I see that this approach is=20 > already used, so it looks like a good idea to me. However, in there, > the=20 > string is slightly sanitized, so that '\0' in the middle of the > string=20 > are turned into ' ', and the final character is always set to '\0'. I > think you could probably do the same here. Here we are interested only in the filename, so ending the C string at the first '\0' is what we need. > > -=C2=A0 if (fname =3D=3D NULL || fname.get ()[0] =3D=3D '\0') > > +=C2=A0 if (buf_len < 1 || fname.get ()[0] =3D=3D '\0') > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* No program name was read,= so we won't be able to > > retrieve more > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information about the = process.=C2=A0 */ > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return 0; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > > +=C2=A0 if (fname.get ()[buf_len - 1] !=3D '\0') > If you don't do the same, at least here the last character should be=20 > changed. Its pretty dangerous to allow it to pass since like 5 lines=20 > later this is used as a C-string, so you could get read-past-the-end > and=20 > other nasty problems. Oh, right - I think I should just return here. /proc/.../cmdline not having a trailing '\0' must be a kernel bug anyway.