| Message ID | 20180731211404.2eac1bb0@wiggum (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | b43/leds: Ensure NUL-termination of LED name string | expand |
Michael Büsch <m@bues.ch> writes: > strncpy might not NUL-terminate the string, if the name equals the buffer size. > Use strlcpy instead. > > Signed-off-by: Michael Buesch <m@bues.ch> > Cc: stable@vger.kernel.org This is weird, with all the patches you submitted last week I get this if I download the patch from patchwork: $ git am -s 1.mbox Patch is empty. Was it split wrong? But if I download the patch directly from my IMAP folder I have no problems: $ git am -s 1.mbox Applying: b43/leds: Ensure NUL-termination of LED name string This happens even without my custom patchwork script so this has something to do with the patchwork server, but it's not obvious to me what triggers it. IIRC I have not seen anything like this before. It seems that you didn't use git-send-email, I strongly suggest to use that just to avoid problems like this. Anyway, applied manually: 2aa650d1950f b43/leds: Ensure NUL-termination of LED name string
On 9 August 2018 at 17:28, Kalle Valo <kvalo@qca.qualcomm.com> wrote: > Michael Büsch <m@bues.ch> writes: > >> strncpy might not NUL-terminate the string, if the name equals the buffer size. >> Use strlcpy instead. >> >> Signed-off-by: Michael Buesch <m@bues.ch> >> Cc: stable@vger.kernel.org > > This is weird, with all the patches you submitted last week I get this > if I download the patch from patchwork: > > $ git am -s 1.mbox > Patch is empty. Was it split wrong? > > But if I download the patch directly from my IMAP folder I have no > problems: > > $ git am -s 1.mbox > Applying: b43/leds: Ensure NUL-termination of LED name string > > This happens even without my custom patchwork script so this has > something to do with the patchwork server, but it's not obvious to me > what triggers it. IIRC I have not seen anything like this before. It > seems that you didn't use git-send-email, I strongly suggest to use that > just to avoid problems like this. Looks like patchwork mishandles the pgp signature, the patchwork mbox has > Content-Type: multipart/signed; micalg=pgp-sha512; > boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" as the only content-type (and the boundary is nowhere to be found), while the one in my inbox has > Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" > > --Sig_/EN90ciRq4eWXDUcnZABQ0Ak > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable When I remove the Content-Type: line(s) from the mbox from patchwork, git recognises it again as a patch. I guess git am ignores everything until the boundary, which got dropped by patchwork, so it never finds the actual patch. Regards Jonas
Jonas Gorski <jonas.gorski@gmail.com> writes: > On 9 August 2018 at 17:28, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >> Michael Büsch <m@bues.ch> writes: >> >>> strncpy might not NUL-terminate the string, if the name equals the buffer size. >>> Use strlcpy instead. >>> >>> Signed-off-by: Michael Buesch <m@bues.ch> >>> Cc: stable@vger.kernel.org >> >> This is weird, with all the patches you submitted last week I get this >> if I download the patch from patchwork: >> >> $ git am -s 1.mbox >> Patch is empty. Was it split wrong? >> >> But if I download the patch directly from my IMAP folder I have no >> problems: >> >> $ git am -s 1.mbox >> Applying: b43/leds: Ensure NUL-termination of LED name string >> >> This happens even without my custom patchwork script so this has >> something to do with the patchwork server, but it's not obvious to me >> what triggers it. IIRC I have not seen anything like this before. It >> seems that you didn't use git-send-email, I strongly suggest to use that >> just to avoid problems like this. > > Looks like patchwork mishandles the pgp signature, the patchwork mbox has > >> Content-Type: multipart/signed; micalg=pgp-sha512; >> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" > > as the only content-type (and the boundary is nowhere to be found), > while the one in my inbox has > >> Content-Type: multipart/signed; micalg=pgp-sha512; >> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; >> protocol="application/pgp-signature" >> >> --Sig_/EN90ciRq4eWXDUcnZABQ0Ak >> Content-Type: text/plain; charset=US-ASCII >> Content-Transfer-Encoding: quoted-printable > > When I remove the Content-Type: line(s) from the mbox from patchwork, > git recognises it again as a patch. I guess git am ignores everything > until the boundary, which got dropped by patchwork, so it never finds > the actual patch. Awesome, thanks for debugging this! It would be great if someone could report this to the patchwork maintainers, I don't have the time right now.
On 9 August 2018 at 18:15, Kalle Valo <kvalo@codeaurora.org> wrote: > Jonas Gorski <jonas.gorski@gmail.com> writes: > >> On 9 August 2018 at 17:28, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >>> Michael Büsch <m@bues.ch> writes: >>> >>>> strncpy might not NUL-terminate the string, if the name equals the buffer size. >>>> Use strlcpy instead. >>>> >>>> Signed-off-by: Michael Buesch <m@bues.ch> >>>> Cc: stable@vger.kernel.org >>> >>> This is weird, with all the patches you submitted last week I get this >>> if I download the patch from patchwork: >>> >>> $ git am -s 1.mbox >>> Patch is empty. Was it split wrong? >>> >>> But if I download the patch directly from my IMAP folder I have no >>> problems: >>> >>> $ git am -s 1.mbox >>> Applying: b43/leds: Ensure NUL-termination of LED name string >>> >>> This happens even without my custom patchwork script so this has >>> something to do with the patchwork server, but it's not obvious to me >>> what triggers it. IIRC I have not seen anything like this before. It >>> seems that you didn't use git-send-email, I strongly suggest to use that >>> just to avoid problems like this. >> >> Looks like patchwork mishandles the pgp signature, the patchwork mbox has >> >>> Content-Type: multipart/signed; micalg=pgp-sha512; >>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" >> >> as the only content-type (and the boundary is nowhere to be found), >> while the one in my inbox has >> >>> Content-Type: multipart/signed; micalg=pgp-sha512; >>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; >>> protocol="application/pgp-signature" >>> >>> --Sig_/EN90ciRq4eWXDUcnZABQ0Ak >>> Content-Type: text/plain; charset=US-ASCII >>> Content-Transfer-Encoding: quoted-printable >> >> When I remove the Content-Type: line(s) from the mbox from patchwork, >> git recognises it again as a patch. I guess git am ignores everything >> until the boundary, which got dropped by patchwork, so it never finds >> the actual patch. > > Awesome, thanks for debugging this! It would be great if someone could > report this to the patchwork maintainers, I don't have the time right > now. Silly question, but who *are* the maintainers? I just spend several minutes on https://patchwork.kernel.org/ and google, and failed to find any contact information. Regards Jonas
Jonas Gorski <jonas.gorski@gmail.com> writes: > On 9 August 2018 at 18:15, Kalle Valo <kvalo@codeaurora.org> wrote: >> Jonas Gorski <jonas.gorski@gmail.com> writes: >> >>> On 9 August 2018 at 17:28, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >>>> Michael Büsch <m@bues.ch> writes: >>>> >>>>> strncpy might not NUL-terminate the string, if the name equals the buffer size. >>>>> Use strlcpy instead. >>>>> >>>>> Signed-off-by: Michael Buesch <m@bues.ch> >>>>> Cc: stable@vger.kernel.org >>>> >>>> This is weird, with all the patches you submitted last week I get this >>>> if I download the patch from patchwork: >>>> >>>> $ git am -s 1.mbox >>>> Patch is empty. Was it split wrong? >>>> >>>> But if I download the patch directly from my IMAP folder I have no >>>> problems: >>>> >>>> $ git am -s 1.mbox >>>> Applying: b43/leds: Ensure NUL-termination of LED name string >>>> >>>> This happens even without my custom patchwork script so this has >>>> something to do with the patchwork server, but it's not obvious to me >>>> what triggers it. IIRC I have not seen anything like this before. It >>>> seems that you didn't use git-send-email, I strongly suggest to use that >>>> just to avoid problems like this. >>> >>> Looks like patchwork mishandles the pgp signature, the patchwork mbox has >>> >>>> Content-Type: multipart/signed; micalg=pgp-sha512; >>>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" >>> >>> as the only content-type (and the boundary is nowhere to be found), >>> while the one in my inbox has >>> >>>> Content-Type: multipart/signed; micalg=pgp-sha512; >>>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; >>>> protocol="application/pgp-signature" >>>> >>>> --Sig_/EN90ciRq4eWXDUcnZABQ0Ak >>>> Content-Type: text/plain; charset=US-ASCII >>>> Content-Transfer-Encoding: quoted-printable >>> >>> When I remove the Content-Type: line(s) from the mbox from patchwork, >>> git recognises it again as a patch. I guess git am ignores everything >>> until the boundary, which got dropped by patchwork, so it never finds >>> the actual patch. >> >> Awesome, thanks for debugging this! It would be great if someone could >> report this to the patchwork maintainers, I don't have the time right >> now. > > Silly question, but who *are* the maintainers? I just spend several > minutes on https://patchwork.kernel.org/ and google, and failed to > find any contact information. Not a silly question at all. I'm not sure what's the preferred way to report bugs but at least I found this: http://jk.ozlabs.org/projects/patchwork/ I guess they use the github tracker: https://github.com/getpatchwork/patchwork/issues/
On 9 August 2018 at 19:01, Kalle Valo <kvalo@codeaurora.org> wrote: > Jonas Gorski <jonas.gorski@gmail.com> writes: > >> On 9 August 2018 at 18:15, Kalle Valo <kvalo@codeaurora.org> wrote: >>> Jonas Gorski <jonas.gorski@gmail.com> writes: >>> >>>> On 9 August 2018 at 17:28, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >>>>> Michael Büsch <m@bues.ch> writes: >>>>> >>>>>> strncpy might not NUL-terminate the string, if the name equals the buffer size. >>>>>> Use strlcpy instead. >>>>>> >>>>>> Signed-off-by: Michael Buesch <m@bues.ch> >>>>>> Cc: stable@vger.kernel.org >>>>> >>>>> This is weird, with all the patches you submitted last week I get this >>>>> if I download the patch from patchwork: >>>>> >>>>> $ git am -s 1.mbox >>>>> Patch is empty. Was it split wrong? >>>>> >>>>> But if I download the patch directly from my IMAP folder I have no >>>>> problems: >>>>> >>>>> $ git am -s 1.mbox >>>>> Applying: b43/leds: Ensure NUL-termination of LED name string >>>>> >>>>> This happens even without my custom patchwork script so this has >>>>> something to do with the patchwork server, but it's not obvious to me >>>>> what triggers it. IIRC I have not seen anything like this before. It >>>>> seems that you didn't use git-send-email, I strongly suggest to use that >>>>> just to avoid problems like this. >>>> >>>> Looks like patchwork mishandles the pgp signature, the patchwork mbox has >>>> >>>>> Content-Type: multipart/signed; micalg=pgp-sha512; >>>>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" >>>> >>>> as the only content-type (and the boundary is nowhere to be found), >>>> while the one in my inbox has >>>> >>>>> Content-Type: multipart/signed; micalg=pgp-sha512; >>>>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; >>>>> protocol="application/pgp-signature" >>>>> >>>>> --Sig_/EN90ciRq4eWXDUcnZABQ0Ak >>>>> Content-Type: text/plain; charset=US-ASCII >>>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> When I remove the Content-Type: line(s) from the mbox from patchwork, >>>> git recognises it again as a patch. I guess git am ignores everything >>>> until the boundary, which got dropped by patchwork, so it never finds >>>> the actual patch. >>> >>> Awesome, thanks for debugging this! It would be great if someone could >>> report this to the patchwork maintainers, I don't have the time right >>> now. >> >> Silly question, but who *are* the maintainers? I just spend several >> minutes on https://patchwork.kernel.org/ and google, and failed to >> find any contact information. > > Not a silly question at all. I'm not sure what's the preferred way to > report bugs but at least I found this: > > http://jk.ozlabs.org/projects/patchwork/ > > I guess they use the github tracker: > > https://github.com/getpatchwork/patchwork/issues/ Going through the issues, I guess this is already fixed in master with https://github.com/getpatchwork/patchwork/commit/e27ff061dc01e51967a978884a5c59152863ab9c and queued for the next 2.1 release (or not? the stable/2.1 branch also contains a version bump to 2.2 ... ) I have still no idea who runs the patchwork instance at patchwork.kernel.org though. Regards Jonas
Jonas Gorski <jonas.gorski@gmail.com> writes: > On 9 August 2018 at 19:01, Kalle Valo <kvalo@codeaurora.org> wrote: >> Jonas Gorski <jonas.gorski@gmail.com> writes: >> >>> On 9 August 2018 at 18:15, Kalle Valo <kvalo@codeaurora.org> wrote: >>>> Jonas Gorski <jonas.gorski@gmail.com> writes: >>>> >>>>> On 9 August 2018 at 17:28, Kalle Valo <kvalo@qca.qualcomm.com> wrote: >>>>>> Michael Büsch <m@bues.ch> writes: >>>>>> >>>>>>> strncpy might not NUL-terminate the string, if the name equals the buffer size. >>>>>>> Use strlcpy instead. >>>>>>> >>>>>>> Signed-off-by: Michael Buesch <m@bues.ch> >>>>>>> Cc: stable@vger.kernel.org >>>>>> >>>>>> This is weird, with all the patches you submitted last week I get this >>>>>> if I download the patch from patchwork: >>>>>> >>>>>> $ git am -s 1.mbox >>>>>> Patch is empty. Was it split wrong? >>>>>> >>>>>> But if I download the patch directly from my IMAP folder I have no >>>>>> problems: >>>>>> >>>>>> $ git am -s 1.mbox >>>>>> Applying: b43/leds: Ensure NUL-termination of LED name string >>>>>> >>>>>> This happens even without my custom patchwork script so this has >>>>>> something to do with the patchwork server, but it's not obvious to me >>>>>> what triggers it. IIRC I have not seen anything like this before. It >>>>>> seems that you didn't use git-send-email, I strongly suggest to use that >>>>>> just to avoid problems like this. >>>>> >>>>> Looks like patchwork mishandles the pgp signature, the patchwork mbox has >>>>> >>>>>> Content-Type: multipart/signed; micalg=pgp-sha512; >>>>>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; protocol="application/pgp-signature" >>>>> >>>>> as the only content-type (and the boundary is nowhere to be found), >>>>> while the one in my inbox has >>>>> >>>>>> Content-Type: multipart/signed; micalg=pgp-sha512; >>>>>> boundary="Sig_/EN90ciRq4eWXDUcnZABQ0Ak"; >>>>>> protocol="application/pgp-signature" >>>>>> >>>>>> --Sig_/EN90ciRq4eWXDUcnZABQ0Ak >>>>>> Content-Type: text/plain; charset=US-ASCII >>>>>> Content-Transfer-Encoding: quoted-printable >>>>> >>>>> When I remove the Content-Type: line(s) from the mbox from patchwork, >>>>> git recognises it again as a patch. I guess git am ignores everything >>>>> until the boundary, which got dropped by patchwork, so it never finds >>>>> the actual patch. >>>> >>>> Awesome, thanks for debugging this! It would be great if someone could >>>> report this to the patchwork maintainers, I don't have the time right >>>> now. >>> >>> Silly question, but who *are* the maintainers? I just spend several >>> minutes on https://patchwork.kernel.org/ and google, and failed to >>> find any contact information. >> >> Not a silly question at all. I'm not sure what's the preferred way to >> report bugs but at least I found this: >> >> http://jk.ozlabs.org/projects/patchwork/ >> >> I guess they use the github tracker: >> >> https://github.com/getpatchwork/patchwork/issues/ > > Going through the issues, I guess this is already fixed in master with > > https://github.com/getpatchwork/patchwork/commit/e27ff061dc01e51967a978884a5c59152863ab9c > > and queued for the next 2.1 release (or not? the stable/2.1 branch > also contains a version bump to 2.2 ... ) Very nice, thanks so much for investigating this! > I have still no idea who runs the patchwork instance at > patchwork.kernel.org though. The admins are Linux Foundation's IT group and one can file a ticket via helpdesk@kernel.org But IMHO there's no need to do that, this is the first time I'm seeing the bug and it can easily wait until patchwork.kernel.org is updated anyway. As long as the issue is fixed upstream.
diff --git a/drivers/net/wireless/broadcom/b43/leds.c b/drivers/net/wireless/broadcom/b43/leds.c index cb987c2ecc6b..87131f663292 100644 --- a/drivers/net/wireless/broadcom/b43/leds.c +++ b/drivers/net/wireless/broadcom/b43/leds.c @@ -131,7 +131,7 @@ static int b43_register_led(struct b43_wldev *dev, struct b43_led *led, led->wl = dev->wl; led->index = led_index; led->activelow = activelow; - strncpy(led->name, name, sizeof(led->name)); + strlcpy(led->name, name, sizeof(led->name)); atomic_set(&led->state, 0); led->led_dev.name = led->name;
strncpy might not NUL-terminate the string, if the name equals the buffer size. Use strlcpy instead. Signed-off-by: Michael Buesch <m@bues.ch> Cc: stable@vger.kernel.org --- drivers/net/wireless/broadcom/b43/leds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)