[SPAM Warning!]Re: U-Boot TFTP OACK option parser reads past unterminated values

Wed May 27 21:15:06 CEST 2026

On May 27, 2026 7:55:58 PM GMT+01:00, "Lee, Brian J"
<hibrian827 at gatech.edu> wrote:
>Thank you for the acknowledgements! I apologize reproducing the PoC had
>difficulties due to poor quality. I will make sure to improve that. Thank
>you!
>
>Best regards,
>Brian

Don't worry, it's not your fault. Asan just doesn't work for some reason :)

>________________________________
>보낸 사람: Josh Law <josh2 at disroot.org>
>보낸 날짜: 2026년 5월 27일 수요일 오후 1:16
>받는 사람: u-boot at lists.denx.de <u-boot at lists.denx.de>; Lee, Brian J
><hibrian827 at gatech.edu>; u-boot at lists.denx.de <u-boot at lists.denx.de>
>참조: Kim, Youngjoon <ykim3186 at gatech.edu>
>제목: Re: U-Boot TFTP OACK option parser reads past unterminated values
>
>[josh2 at disroot.org 전자 메일을 받지 않는 경우가 많습니다.
>https://aka.ms/LearnAboutSenderIdentification ]에서 중요한 이유 알아보기
>
>On May 27, 2026 5:17:43 PM GMT+01:00, "Lee, Brian J"
><hibrian827 at gatech.edu> wrote:
>>Hello U-Boot Security Team,
>>
>>My name is Brian Lee, and I am a PhD Security Researcher in SSLab at
>>Georgia Tech. I'd like to privately report a potential denial-of-service
>>issue due to insufficient scan termination in OACK option parser in TFTP.
>>A remote unauthenticated TFTP server selected by the U-Boot client, or an
>>attacker able to spoof the expected server's first OACK to the client's
>>TFTP source port, can send a single malformed OACK during an ordinary
>TFTP
>>get, boot, or update flow.
>>
>>Target:
>>
>>  *
>>Project: u-boot
>>  *
>>Repo:
>https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fu-boot%2Fu-boot&data=05%7C02%7Chibrian827%40gatech.edu%7C8045df0c917e421446b708debc13a9b9%7C482198bbae7b4b258b7a6d7f32faa083%7C1%7C0%7C639154989808357367%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=tYqLck9YuSDv199v05buMvw11w99PFocY2rIs69wDy8%3D&reserved=0<https://github.com/u-boot/u-boot>
>>  *
>>Pinned ref: 215496fec59b3fa09256b4fb62f92af46e2ec7f9
>>
>>Threat model:
>>
>>U-Boot documents TFTP boot/download commands and optional automatic TFTP
>>update; a selected or spoofed TFTP server can send the first OACK without
>>authentication. The required packet is a single malformed OACK during an
>>ordinary TFTP RRQ flow, with no credentials or multi-step race beyond
>>being the selected/spoofed server response.
>>
>>Attached:
>>
>>  *
>>README.md : full writeup.
>>  *
>>poc/run.sh :  allocates an exact-length TFTP packet containing opcode
>>0x0006 (OACK), option name blksize, a NUL after the option name, and one
>>value byte (5) without the required value-terminating NUL. It then calls
>>the modeled tftp_handler() as the first server response to a client RRQ,
>>with destination port 1069 and source port 69, matching the guard state
>>that accepts an initial OACK before the remote port is pinned.
>>  *
>>poc/inputs: the relevant files for running poc
>>
>>I would like to get help from your expertise to clarify whether this is a
>>valid security threat or not. Thank you.
>>
>>Best Regards,
>>Brian Lee
>>
>>
>
>Hey Brian,
>
>These bugs look plausible to me.
>
>If maintainers want fixes tags,
>
>For OACK:
>Fixes: 53a5c424bf86 ("multicast tftp: RFC2090")
>
>
>For short ack:
>Fixes: 1fb7cd498e6a ("net: tftpput: implement tftp logic")
>
>I don't think the error case needs a fixes tag, it came up on the very
>first commit.
>
>
>I tried testing on my arm box using your script:
>
>AddressSanitizer: CHECK failed: sanitizer_allocator_primary64.h:131
>  "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize,
>  PrimaryAllocatorName, kSpaceBeg)))"
>  (0x500000000000, 0xfffffffffffffff4) (tid=3186)
>      <empty stack>
>
>
>
>it seems to be a "my host" issue
>
>
>
>Note: I reproed under valgrind:
>
>
>josh at armbox:~$ valgrind --quiet --error-exitcode=99
>/tmp/brian-u-boot-pocs/
>  oack_vg; echo "exit=$?"
>  ==3366== Invalid read of size 1
>  ==3366==    at 0x108A08: dectoul (harness.c:33)
>  ==3366==    by 0x108B93: tftp_handler (harness.c:119)
>  ==3366==    by 0x108E8F: main (harness.c:182)
>  ==3366==  Address 0x4a8f04b is 0 bytes after a block of size 11 alloc'd
>  ==3366==    at 0x488545C: malloc (vg_replace_malloc.c:446)
>  ==3366==    by 0x108E4B: main (harness.c:176)
>
>  ==3366== Invalid read of size 1
>  ==3366==    at 0x488E7A4: __GI_strlen (vg_replace_strmem.c:506)
>  ==3366==    by 0x491CC87: printf (printf.c:33)
>  ==3366==    by 0x108BCF: tftp_handler (harness.c:120)
>
>  Blocksize oack: 5, 5
>  exit=99
>
>  josh at armbox:~$ valgrind --quiet --error-exitcode=99 /tmp/brian-u-boot-pocs/
>  ack_vg; echo "exit=$?"
>  ==3367== Invalid read of size 2
>  ==3367==    at 0x108A1C: tftp_handler (uboot_tftp_ack_harness.c:67)
>  ==3367==    by 0x108BEB: main (uboot_tftp_ack_harness.c:111)
>  ==3367==  Address 0x4a8f042 is 0 bytes after a block of size 2 alloc'd
>  ==3367==    at 0x488545C: malloc (vg_replace_malloc.c:446)
>  ==3367==    by 0x108BA3: main (uboot_tftp_ack_harness.c:104)
>
>  exit=99
>
>  josh at armbox:~$ valgrind --quiet --error-exitcode=99 /tmp/brian-u-boot-pocs/
>  error_vg; echo "exit=$?"
>  ==3368== Invalid read of size 2
>  ==3368==    at 0x108A78: tftp_handler (uboot_tftp_error_harness.c:58)
>
>  ==3368== Invalid read of size 1
>  ==3368==    at 0x488E788: __GI_strlen (vg_replace_strmem.c:506)
>  ==3368==    by 0x491CC87: printf (printf.c:33)
>  ==3368==    by 0x108A97: tftp_handler (uboot_tftp_error_harness.c:57)
>
>  ==3368== Invalid read of size 2
>  ==3368==    at 0x108A9C: tftp_handler (uboot_tftp_error_harness.c:60)
>
>  TFTP error: '' (0)
>  Starting again
>
>  exit=99
>
>Thanks!
>

Thanks!