Message ID | 1510594506.5755.119.camel@cavium.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 53118 invoked by alias); 13 Nov 2017 17:35:14 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 52905 invoked by uid 89); 13 Nov 2017 17:35:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Yay, Yay!, Apparently X-HELO: NAM01-SN1-obe.outbound.protection.outlook.com Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Steve.Ellcey@cavium.com; Message-ID: <1510594506.5755.119.camel@cavium.com> Subject: Re: [PATCH] add attribute nonstring From: Steve Ellcey <sellcey@cavium.com> Reply-To: sellcey@cavium.com To: Martin Sebor <msebor@gmail.com>, Paul Eggert <eggert@cs.ucla.edu> Cc: GNU C Library <libc-alpha@sourceware.org> Date: Mon, 13 Nov 2017 09:35:06 -0800 In-Reply-To: <06e1ee69-bb30-ff95-42db-2d4b2d7eba7d@gmail.com> References: <06e1ee69-bb30-ff95-42db-2d4b2d7eba7d@gmail.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SN4PR0501CA0130.namprd05.prod.outlook.com (10.167.128.47) To DM5PR07MB3548.namprd07.prod.outlook.com (10.164.153.146) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: baf7ccc1-9558-403b-918b-08d52abce334 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR07MB3548; X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3548; 3:oGrhMPF8mfRDxYHQ6U6t1Zz9audufwmUKAvJHdfgYBjs3U1gxdid7k8SYLdst+rIlDVFrjL3xhDBJ9DhKM9liS3Wa1ThZ5ewM9W2HdrJvgM4W8lXSUj6kTyi/rWj5CAHN+ZBwwhD7n+NaMswLUotS9ysIS0XqcJkCNOGFFruSbUV5h8+gEyP5Ah5ydiLB2/5eXbD3PmxvDDOVySYR7MGT4J3LEcByYBsQQ4b+mJPksQBQXWf1HmfosWORoxuL6sj; 25:1i4siZ0vj4M9FNiY4Yz03jUR7MtTuuW+VKSHOq2KC9vAxcJs7iJKQJ4q6a/0heQzMBvTMjAUQyn/EapuJaKfoARtmL6gJeYJoKwKceduu2mR0nx8hYaKWbEY3qCVmi2Pj4rBPsFDg0GIpFhf9WO7MwxDV4kB85mQqizTty0Id6JWVP0DUpeJAgUCGYtHpBcOkOFIeb9Te2LklgnVQA54QW2tYZTpgXvfZ4XcB/Zl8vOwYsSzQI/fmNBUR2y1oD8SWfUUIrh0EtXJiLD92fUTUJvjbb0ccZvxy4Y/mU/MUjNzq8pB/eoCUhzO223EI711EbF+gtMaX6yFxc/79B0MHA==; 31:7eJRl549Nai3ZZLM4eSJptCjJ1dEy9wwgc9hsRmfgWOdaUXnYRP1TsSG58lWCpsof/J+pLdUVzxMOdwFP8Mwmi1cwiZztVpbEk7GhSC5Eu8RTFsdEOrcpMptVHmRFiFvbTUibirn+Fonyn7BzvUvU/VNl3QoefXG/PZbbsh/8rRfWsWLTgDBh6lYalYCZO0mthWOoT9QN0XTBbQKfmPwdhYuw8s0dMGoVZyR+ukDPVY= X-MS-TrafficTypeDiagnostic: DM5PR07MB3548: X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3548; 20:d9aXzuwX43+fP1KSS2bmGH+rmfFtACQ618YSx/YE50seiVwnlL+ijkyhVfUzwy8Pd7q+BWgkNHidj2dZC4dSYybpVslbJ9gMbG+3SFq39XfTJ85NaY2tZ4elSejqDs5nLU5OFdT3kiuxqxQBt004cadkNAEulr/V6dp/mpMN+QNmGXhhjeudHwxP6ijVfX5i8ihTnHtEFG/SeDHKaXOMgimCphtu3p1yhp0VQiZf/es2NHMuHx/gUrlMBJie1ONQG9vedN/y/iiDlz+tw3otFYcgagzgxNibaIeMLHJ6VTEE8iS0zly122bcdO2GSRNUy5PtQSl1rB+LOJcZdHiVIOlH2MC3As62yg0Ohu3wbu1pI7xwepC6KO8Urx06XEwysqETm8nddXDriK8kZM0xbKZubJOR+DB//0xD58XwhbVZiMAX1ctMlWfAwaNGhIfNUZFuDsb1+JYsu96y1sA4yE8b9fffm8RKdFDlEVApQSTZZbQ2mhxgYiaf6CyyWOFD; 4:XkqB//bHof2pKnVhAeS8+7Af5lffgNZ7PZrEwvWh25A0xrscRFQnJFpml8SN0/I5KTLwX9VLd7//maMkPbrA4IHD/fyWIXa3ZqM8tXPo7jgMJEjcPjkPytyf5LRzN0OQsxgXjRBBTg+Mv/ljNe4DAOqJ1Jpu+nUfPcL3qf32Ni1fxhIN9zU5EN93Xo63FGVebtNBaQsNFhG2ruqqI7zu3ltCkVamuf7oaDMC7kDLy9YW3e5FuBs14EGyZRmjonMMnJVMZHSZeLI/qCadx8DG+tMwuWWB6x1JkJ31jA2cSyT/gr8sf1xVl5nChswL91bhsHG+KWaqhNaipx4XppdNRN8IvgQF7eGcokIO+ok9H+Y= X-Microsoft-Antispam-PRVS: <DM5PR07MB354846A398FD0D61D1CEF91CF52B0@DM5PR07MB3548.namprd07.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(55632472524450)(104084551191319); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR07MB3548; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR07MB3548; X-Forefront-PRVS: 0490BBA1F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(377424004)(24454002)(4326008)(6116002)(2171002)(101416001)(6246003)(316002)(53936002)(478600001)(69596002)(110136005)(189998001)(76176999)(50986999)(33646002)(103116003)(50226002)(16526018)(6666003)(43066004)(966005)(72206003)(2950100002)(39060400002)(81156014)(229853002)(8936002)(3846002)(8676002)(50466002)(81166006)(105586002)(106356001)(25786009)(7736002)(3450700001)(305945005)(5660300001)(68736007)(6506006)(2906002)(6486002)(2870700001)(6306002)(36756003)(53416004)(66066001)(23676003)(97736004)(47776003)(4001150100001)(6512007)(5820100001)(99106002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR07MB3548; H:sellcey-dt.caveonetworks.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtETTVQUjA3TUIzNTQ4OzIzOmdkdXVDZmsyejhVK0loTmx0dHhqN3dTYWFN?= =?utf-8?B?Sm01ZTg5TExzciszL0NtR05tQUpRVUVUZ2pWZlR4Wm1ZUnlheDFoK1UzOGdu?= =?utf-8?B?WHVuYzFiMWRLR2RpUFJndXhHZEdIT1Y1NVcxUlF4R3lGRnJMTnJOZ0pFamh4?= =?utf-8?B?RWRCOUpUenZlaVRPY0YraXo0OWVETjFPRFV1VWlUcEZRR0lMWGRuVS9OOEIw?= =?utf-8?B?NU84bXlpRFhFMSs1Q2JTcndVQVVHemIyajNpNTdwam9pOXlHY1pTZ1dtaEtH?= =?utf-8?B?SW9YaklIS3hpWnJWdXBpTGFWZFllU3k0bDYreE5vYno5UXJpcHV5MDJwUkpW?= =?utf-8?B?WjVMelNhMzRXWHQ0ZVJua01DeTRFUHhaK2NPY2JzOEdTRVlEV3MyMTFzdThX?= =?utf-8?B?MitpN2VRN2ZYQU4wOGhrRjMzVGF3QXM0TUZtVDBLd0NrU1RtTlFuOWRmNU84?= =?utf-8?B?ZzFiaW9lcEJ4cHpPTjFDUUpJN1FrL0lBZFdTOUtWdWFZclN1YzFDRGQzeWVl?= =?utf-8?B?MWN2UnhMdFVjaEh5eHMvNmhzaWRLQzd6a1dsQUdGWk11ZzNVNzFKOGYxelVZ?= =?utf-8?B?aTB2NlVMOHc4UmlSYWZiRm51WmVNVndsUjZrZXRvaVR6VEhQVFdzejRZV3dj?= =?utf-8?B?Q3hCRW91dGhRVGdjNk5YRXluR080SFhKZC9vbmNmMWVlaEFpcWh0bkY0clFS?= =?utf-8?B?NDRrUmVZN1FoK3Y4NnB6ZmpPVGZBMTg2OW9Yb2FpQXovVmczUHJ0VFlXSXlt?= =?utf-8?B?MnZHMGQwNzB6VXVKWnNaMks0MnJ0VHhONmFoZFIyRTl2eVEzL2tUYU5SKzVs?= =?utf-8?B?STAwbFdkNzZyYU9TTXJ4RUhJMTRRdC9DK1NHMjJXa2l3Q1AzZzRDUlJWbVZr?= =?utf-8?B?K1VETnI2OFg5ZVBzdTJZZWg0K0JzRFRVQStPQlI5VWFINi9NV2JMU2oxV3cz?= =?utf-8?B?enhvUGhuOXM1MS9uTml4ODF4Sm94QlNXV2dSc1FoRTF3M3dlVFVxa0ovRGV2?= =?utf-8?B?OFJGb2QyRXdlRWxTN1pudEY3K1pGNFh1ZHR2UmhNcEUzVUlVc2xUZDlLaE5M?= =?utf-8?B?NTdFbnFxcElvVzg3N3ltMUYxa3dwaUJQRlNaSDVJeXdVTnluMGFxeW5uaDI1?= =?utf-8?B?R0s4V0dRS1ZyejBranNTS2VNK05TMlY2bmczYVhIZ0tiZzRkd3V4ZDc3VSs3?= =?utf-8?B?YlFKTlJQT2VRb3NhR0FtUXUwSVBrT2NDN1F0Q0Q2aHBjdEI3MW1PbnROOW1h?= =?utf-8?B?NzY4b0xqbTJBTEp5dTk2VHQ1UnVjVjNGTzM1T3oyTlA0MHluQlVJdDBTS0pC?= =?utf-8?B?VVBSWGUyRDY0bVhmSHp4UWdWOGEvT2gvN2N2eHJHWnZZVWFueUFRbjZ5Qmwx?= =?utf-8?B?VE9IKzUwdHBMK2dVQXdRSmVBT3BpWUh1YVhqTXA1WkFzSGNJeHdQUTlDeW1j?= =?utf-8?B?M1k4NHFRMy9QUFBVU3A4NUxHUGx2SUx5UXRsSG5vbC9RZ1A3Y2gyMyttTkFP?= =?utf-8?B?Mit4QWdURUtTQjJXZnAxQmcyVlNvTUJUUFl6WCtyR1hPS05YWkVURXQ4OGI2?= =?utf-8?B?MU94Sy9YamFjOWhOOTExSUFWcXA3UTlFa0U1b3BUZ0hvemt0b3c4U1d2MDN2?= =?utf-8?B?R3h1L25sUzNXSzZIMGhpZ01Oazh2TzFyTi9VTzY2MEVKTU9UVGFNeUhqOGV1?= =?utf-8?B?ZjgzdnhTSUpEOVU1REtoNUtXeUhxQVllOWJVekNwSURYZlBXWkkvU3VLKzgx?= =?utf-8?B?ck1DUGNieGs2L05mQUR0NVQzSDR3ZUNqM0M3RmRweldSdGF4WUxjZFQ2b0sy?= =?utf-8?B?TkI5SUV2am5GVzEwRmFIRE9WYTEvSDg4T3hLQ1Z6OVErZzZMVCt4SFdGK2JK?= =?utf-8?Q?sYnZoxCNz/5ovJtNBnREJKzfidTyy1u1?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR07MB3548; 6:RKuIJ4lNd+Ckx7I+XLNzdcSKssCXgpY1dQNj/srMdNkUsBc8lrVds4KCAerw4u9vANDWSJUQegpU36j+jjFdGcfqbSAi0NYb5yPQ/WEqYn2bIah6SqeytZC5F9M/Mu73JDPxn1ZWLGSc1q3Kf0nbsr9Jrf7clBb5B0ANrGC0fIssLUSzaj4VU7TR7pIrTw3Id45kGwEzAhbCFRnLzAznXM+nf14qlXOf8Wq6IqrAaJWyk4bbAVyWA8KQQW3QRPkbDihOkbd70SQvBVXeW6P7nc3T66Ux5YUM4P2sVizc6WfOrxn+/ZmpzzV7l0F2dt/ob+LJPOglNuJzkIAXFsg/lGqMcIJnlTQ/U1axi6mYFNA=; 5:7bZviLx5wc50mOOQ5pBSegf0pjjwSsmrlwDrI6dnmMVPjNA4AyCpa0AbVuSJAD/tZNm6Tw3smw5cM78SExRhSP795aALC2dj1L/bDPzhBAO3DNDFQOK0o1+gpVSQMQYqXGDnf/Zm0PJzS7TsIHoT+a7E2yUWk+AleojY1rgUZnY=; 24:TeCpxonuHd1P9nCNMB39omgX9vlgDAOBD07adUspt3Tv0XHGv1ayettGAxTMpVkIJeijD2+YrBFGtsr1j//cJPKzQc0M2mv4xKj4or6A8Cw=; 7:jA+Ttm+a534OaoGf2VA0nFArqPnPOcVp2Wt8XmEyycwToAFxCWWSw390Ezk/3DmD4YwmesZciBo7M7y5gBjgRBV0eAntnAtgv5209zSU+ZVQC6XgSE191OVfcY2vMDi+oJ+Dvc0KxCePQPAx244NfFmo49TKagIttthaJVZafbkGnMAB4jwYkWCzrBwBA5qbD/PeLESJvctZ7XEwpXWRmTjQ1WM83guQoktiFSCsHWZfgMoFD7tIbSFNRYabDYzv SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2017 17:35:09.3134 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: baf7ccc1-9558-403b-918b-08d52abce334 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR07MB3548 |
Commit Message
Steve Ellcey
Nov. 13, 2017, 5:35 p.m. UTC
On Sun, 2017-11-12 at 16:49 -0700, Martin Sebor wrote: > > PS I still don't see it discussed on the Linux man page but > I did find such a requirement on an AIX 6.1 ioctl man page: > https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_61/apis/ioct > l.htm > > The descriptions of the if_indextoname and if_nametoindex > functions specified by RFC 3493 also talk about the name being > a nul-terminated string so it looks to me like you are correct > and the warning has found a Glibc bug. Yay! :) I think this is a bug and that if_nametoindex should check for a name that is too long. Based on RFC 3493 it would appear that we don't need to set errno in this case though I am not sure if that is a correct interpretation. I tested this patch: 2017-11-13 Steve Ellcey <sellcey@cavium.com> * sysdeps/unix/sysv/linux/if_index.c (__if_nametoindex): Check if ifname is too long. And it compiled fine using the latest GCC. Apparently GCC's constant propogation allowed it to see that sizeof could not longer be IFNAMSIZ. Steve Ellcey
Comments
On Mon, 13 Nov 2017, Steve Ellcey wrote: > On Sun, 2017-11-12 at 16:49 -0700, Martin Sebor wrote: > > > > PS I still don't see it discussed on the Linux man page but > > I did find such a requirement on an AIX 6.1 ioctl man page: > > https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_61/apis/ioct > > l.htm > > > > The descriptions of the if_indextoname and if_nametoindex > > functions specified by RFC 3493 also talk about the name being > > a nul-terminated string so it looks to me like you are correct > > and the warning has found a Glibc bug. Yay! :) > > I think this is a bug and that if_nametoindex should check for a name > that is too long. Based on RFC 3493 it would appear that we don't need > to set errno in this case though I am not sure if that is a correct > interpretation. I tested this patch: > > > 2017-11-13 Steve Ellcey <sellcey@cavium.com> > > * sysdeps/unix/sysv/linux/if_index.c (__if_nametoindex): > Check if ifname is too long. Florian, any comments on the proper handling of too-long names here, and so on how we should avoid the strncpy warnings in this case?
On 11/13/2017 06:35 PM, Steve Ellcey wrote: > On Sun, 2017-11-12 at 16:49 -0700, Martin Sebor wrote: >> >> PS I still don't see it discussed on the Linux man page but >> I did find such a requirement on an AIX 6.1 ioctl man page: >> https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_61/apis/ioct >> l.htm >> >> The descriptions of the if_indextoname and if_nametoindex >> functions specified by RFC 3493 also talk about the name being >> a nul-terminated string so it looks to me like you are correct >> and the warning has found a Glibc bug. Yay! :) > > I think this is a bug and that if_nametoindex should check for a name > that is too long. Based on RFC 3493 it would appear that we don't need > to set errno in this case though I am not sure if that is a correct > interpretation. I tested this patch: > > > 2017-11-13 Steve Ellcey <sellcey@cavium.com> > > * sysdeps/unix/sysv/linux/if_index.c (__if_nametoindex): > Check if ifname is too long. > > > diff --git a/sysdeps/unix/sysv/linux/if_index.c > b/sysdeps/unix/sysv/linux/if_index.c > index 56f3f13..1e081c0 100644 > --- a/sysdeps/unix/sysv/linux/if_index.c > +++ b/sysdeps/unix/sysv/linux/if_index.c > @@ -43,6 +43,9 @@ __if_nametoindex (const char *ifname) > if (fd < 0) > return 0; > > + if (strlen (ifname) >= IFNAMSIZ) > + return 0; > + > strncpy (ifr.ifr_name, ifname, sizeof (ifr.ifr_name)); > if (__ioctl (fd, SIOCGIFINDEX, &ifr) < 0) > { The Linux kernel has this in include/linux/netdevice.h: | struct net_device { | char name[IFNAMSIZ]; If I traced this correctly, the ioctl compares the passed-in name using strncmp: | struct net_device *dev_get_by_name_rcu(struct net *net, const char *name) | { | struct net_device *dev; | struct hlist_head *head = dev_name_hash(net, name); | | hlist_for_each_entry_rcu(dev, head, name_hlist) | if (!strncmp(dev->name, name, IFNAMSIZ)) | return dev; | | return NULL; | } So this means that we should add the nostring attribute and not the length check. I'll ask one of our networking people to double-check this. Thanks, Florian
On Tue, 14 Nov 2017, Florian Weimer wrote: > So this means that we should add the nostring attribute and not the length > check. If the name passed is actually longer than this field, is it undefined behavior or not? If it's not undefined behavior, I think we should avoid silent truncation (which means a length check, even if the check allows the possibility of a non-NUL-terminated value ending up in the field, unless for some reason truncation is always OK and does not affect the semantics).
On Nov 14 2017, Joseph Myers <joseph@codesourcery.com> wrote: > On Tue, 14 Nov 2017, Florian Weimer wrote: > >> So this means that we should add the nostring attribute and not the length >> check. > > If the name passed is actually longer than this field, is it undefined > behavior or not? The kernel will always zero-terminate the string at IFNAMSIZ-1, see dev_ifname in net/core/dev_ioctl.c. Andreas.
On 11/14/2017 06:55 PM, Andreas Schwab wrote: > On Nov 14 2017, Joseph Myers <joseph@codesourcery.com> wrote: > >> On Tue, 14 Nov 2017, Florian Weimer wrote: >> >>> So this means that we should add the nostring attribute and not the length >>> check. >> >> If the name passed is actually longer than this field, is it undefined >> behavior or not? > > The kernel will always zero-terminate the string at IFNAMSIZ-1, see > dev_ifname in net/core/dev_ioctl.c. Yes, Hannes and I went over the code and reached the same conclusion (for the ioctl interface, netlink is a bit more involved to check). However, the original patch should really use strnlen or memchr, and not strlen. As posted, the strlen is either invalid because the array is not NUL-terminated, or it passes because the string is short enough. Thanks, Florian
On Tue, 14 Nov 2017, Florian Weimer wrote: > However, the original patch should really use strnlen or memchr, and not > strlen. As posted, the strlen is either invalid because the array is not > NUL-terminated, or it passes because the string is short enough. if_nametoindex takes a char * argument. POSIX doesn't say explicitly, but I'd presume that must be a NUL-terminated string, with undefined behavior otherwise. That's separate from what the kernel interface is.
On 11/14/2017 07:27 PM, Joseph Myers wrote: > On Tue, 14 Nov 2017, Florian Weimer wrote: > >> However, the original patch should really use strnlen or memchr, and not >> strlen. As posted, the strlen is either invalid because the array is not >> NUL-terminated, or it passes because the string is short enough. > > if_nametoindex takes a char * argument. POSIX doesn't say explicitly, but > I'd presume that must be a NUL-terminated string, with undefined behavior > otherwise. That's separate from what the kernel interface is. Oh, you are of course right. strlen is fine under these circumstances. So the only thing that's missing is the __set_errno (ENODEV); call, I think. (It's what the ioctl should fail with for an unknown interface name.) Thanks, Florian
diff --git a/sysdeps/unix/sysv/linux/if_index.c b/sysdeps/unix/sysv/linux/if_index.c index 56f3f13..1e081c0 100644 --- a/sysdeps/unix/sysv/linux/if_index.c +++ b/sysdeps/unix/sysv/linux/if_index.c @@ -43,6 +43,9 @@ __if_nametoindex (const char *ifname) Â Â Â if (fd < 0) Â Â Â Â Â return 0; Â +Â Â if (strlen (ifname) >= IFNAMSIZ) +Â Â Â Â return 0; + Â Â Â strncpy (ifr.ifr_name, ifname, sizeof (ifr.ifr_name)); Â Â Â if (__ioctl (fd, SIOCGIFINDEX, &ifr) < 0) Â Â Â Â Â {