September 2019 - U-Boot

Re: [U-Boot] What if ATF can be part of U-Boot source, like SPL?
by Matteo Carlini 05 Sep '19

05 Sep '19

Hi Simon and all, > I have been avoiding this thread but today I attended a talk on ATF and > ARM's approach in general. For the benefits of others, that was me talking at the OSFC conference (video and slides should appear soon here: https://osfc.io/talks/trustedfirmware-org-a-collaborative-effort-into-firmw…). Had a chat with Simon and Jagan afterwards, so repeating my answers here for the records. > ARM seems to be moving towards an approach > of providing increasingly complex source code to add more layers of security > software to fully round out two mostly separate worlds (secure and normal). The requirement of having more complex source code running in the Secure world comes from our partners (SoC vendors, ODMs, OSVs...Google included). For example, multi-tenancy in the Secure world (the possibility of running multiple Trusted OSs owned by different vendors) on an Android phone is a real requirement raised by many manufacturers and by Google. Arm is trying to fulfil this requirement by providing both an architecture and a clean reference implementation to support this and to protect the Normal world from attacks (malicious code) running in the Secure world. Worth noticing that all will be developed, reviewed and tested in public as part of the TrustedFirmware.org project, the new "home" of Trusted Firmware-A (TF-A, the former Arm Trusted Firmware). > I came away with the impression that the two companies are going in > different directions. ARM seems to be heading where Intel was and Intel is > heading back. This is a gross simplification of course. As explained verbally, Arm is going into the same direction it has always gone: open source every piece of software running on an Arm platform (from the very first line of code), including all the Power Management software implementation (PSCI into Trusted Firmware, SCMI into the SCP firmware project - https://github.com/ARM-software/SCP-firmware) and encouraging all our partners to do the same for their platforms ports. You can run a full open source software stack on any Arm platform that has upstream support available and the direction is not going to change with more software running in the Secure world (Secure EL2 included)...it will just be some more open source software. > 1. ARM releases new ATF versions as source drops that firmware projects like > U-Boot expected to take. In fact, not even U-Boot...this is just users picking > up whatever they find That's an accurate description (apart from the fact that releases will be tagged by the TrustedFirmware.org community project, not by Arm as such). We have the Linux Kernel model in mind (despite the BSD license topic) and the requirement to reliably point to a precise Trusted Firmware version running on an Arm device, as much as you do with the Kernel. This is practically impossible today due to the number of different implementations deployed on every device by different manufacturers. And that's the problem we are trying to fix. > 2. ATF keeps getting more complex, adding its own drivers for serial, storage, > etc., duplicating and perhaps conflicting with those in U-Boot Apart from platforms support, the additional software to be developed in the Secure world is meant to implement Arm architecture and Arm specifications, not to bloat the code with unnecessary drivers...moreover, as Andre pointed out, Trusted Firmware runs on many non-U-Boot platforms, so there *might* be overlaps for things that are needed elsewhere. > 3. Over time we end up with binary blobs on ARM that are every bit as > impenetrable as what Intel used to have > 4. Firmware security and open-sourceness suffers, overall. That's definitely not our goal. We'd like to ease the audit/certification process and ultimately the security of the highest privileged firmware running on Arm, by encouraging our partners to adopt a clean EL3 (and in the future Secure EL2) generic firmware (ideally a specific x.y version) and moving all their proprietary/platform code elsewhere in lowest exception levels. That's the goal of the architecture we are working on (described in my talk) and we believe it would ultimately help the Arm firmware security ecosystem in general. If by doing so, partners will still end up deploying binary blobs (signed, certified, whatever), these would be built from the corresponding open source project. I don't see how the situation would be any worst that it is today with proprietary EL3 firmware binaries deployed everywhere (despite all the originating core code being upstream!). From my point of view, it could only evolve towards a more open situation...every partner that we gain on this approach will be a partner bought into more open firmware and increased security. > But in the meantime, I think it makes more sense to incorporate the relevant > parts of ATF into U-Boot and maintain them there, only for the platforms > that U-Boot supports. [...] > So overall I support Jagan's proposal based on the current status quo. Bear in mind that TF-A is undergoing huge developments and it's definitely a well alive and dynamic project, it's not a stable library as libfdt to be copied and held for years with little maintenance. We are adding support for all new Arm architectural security features (Armv8.3 Pointer Authentication, Armv8.5 BTI, Armv8.4 Secure EL2) for devices that will come out soon on the market. Any out of tree fork would need to be maintained quite frequently and stay closely up to date with all recent changes. The way we cope with the process of building and combining multiple firmware projects in Arm is to have some build/manifest scripts that pulls everything together from appropriate repos and build it in the right order with the proper options (have a look at the instructions here https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.gi…) An alternate idea Simon have briefly proposed verbally to me is to harmonise TF-A and U-boot around the Kconfig build system. Simon feel free to expose it properly. We are currently investigating the use of Kconfig for TF-A since the current build system is not scalable any longer, so that's something we can surely discuss together with the TF-A community. And...yes, there's an ever growing community around Trusted Firmware, both for A-class and M-class, that goes well beyond Arm and very much favour collaboration and feedbacks from adopters, contributors, partners...you can reach the TF-A one here tf-a(a)lists.trustedfirmware.org, others here https://lists.trustedfirmware.org/mailman/listinfo. Thanks Matteo IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

1 0

[U-Boot] [PATCH v2 0/3] Introduce idbloader.img target for Makefile
by Matwey V. Kornilov 05 Sep '19

05 Sep '19

Rockchip SoCs reqire the following deployment procedure for TPL/SPL: ./tools/mkimage -n rk3328 -T rksd -d ./tpl/u-boot-tpl.bin idbloader.img cat ./spl/u-boot-spl-dtb.bin >> idbloader.img dd if=idbloader.img of=/dev/mmcblk0 seek=64 The series is organized as the following. First patch introduces idbloader.img target for Makefile. The rest is for keeping the documentation up-to-date. Changes since v2: - fix patch 5 - squash patches 2,3,5 into 2 Matwey V. Kornilov (3): rockchip, Makefile: add idbloader.img target doc: rockchip: use idbloader.img for rk3288, rk3328, rk3399 doc: lion_rk3368: use idbloader.img for rk3368 Makefile | 12 ++++++++++++ board/theobroma-systems/lion_rk3368/README | 4 +--- doc/README.rockchip | 21 ++------------------- 3 files changed, 15 insertions(+), 22 deletions(-) -- 2.16.4

2 5

[U-Boot] [PATCH 1/1] net: nfs: remove superfluous packed attribute
by Heinrich Schuchardt 04 Sep '19

04 Sep '19

With GCC 9.2.1 net/nfs.c leads to multiple errors of type address-of-packed-member. net/nfs.c: In function ‘rpc_req’: net/nfs.c:199:18: error: taking address of packed member of ‘struct rpc_t’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 199 | p = (uint32_t *)&(rpc_pkt.u.call.data); | ^~~~~~~~~~~~~~~~~~~~~~ net/nfs.c: In function ‘nfs_readlink_reply’: net/nfs.c:631:46: error: taking address of packed member of ‘struct rpc_t’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 631 | nfs3_get_attributes_offset(rpc_pkt.u.reply.data); | ~~~~~~~~~~~~~~~^~~~~ LD drivers/block/built-in.o net/nfs.c: In function ‘nfs_read_reply’: net/nfs.c:692:46: error: taking address of packed member of ‘struct rpc_t’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 692 | nfs3_get_attributes_offset(rpc_pkt.u.reply.data); | ~~~~~~~~~~~~~~~^~~~~ struct rpc_t is only used as local variable. It is naturally packed. So there is no need for the attribute packed. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- net/nfs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/nfs.h b/net/nfs.h index a377c90088..68ada0efeb 100644 --- a/net/nfs.h +++ b/net/nfs.h @@ -78,7 +78,7 @@ struct rpc_t { NFS_MAX_ATTRS]; } reply; } u; -} __attribute__((packed)); +}; void nfs_start(void); /* Begin NFS */ -- 2.23.0.rc1

3 3

[U-Boot] [PATCH 1/1] net: nfs: remove superfluous conversions
by Heinrich Schuchardt 04 Sep '19

04 Sep '19

rpc_pkt.u.call.data is an array of uint32_t. There is no need to convert it to uint32_t *. memcpy() expects void * as it 1st and 2nd argument. There is no point in converting pointers to char * before passing them to memcpy(). In ntohl(data[1]) != 0 calling ntohl() is superfluous. If the value is zero, does not depend on the byte order. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- net/nfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/nfs.c b/net/nfs.c index d6a7f8e827..105f990360 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -196,10 +196,10 @@ static void rpc_req(int rpc_prog, int rpc_proc, uint32_t *data, int datalen) rpc_pkt.u.call.vers = htonl(2); /* portmapper is version 2 */ } rpc_pkt.u.call.proc = htonl(rpc_proc); - p = (uint32_t *)&(rpc_pkt.u.call.data); + p = rpc_pkt.u.call.data; if (datalen) - memcpy((char *)p, (char *)data, datalen*sizeof(uint32_t)); + memcpy(p, data, datalen * sizeof(uint32_t)); pktlen = (char *)p + datalen * sizeof(uint32_t) - (char *)&rpc_pkt; @@ -579,7 +579,7 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len) static int nfs3_get_attributes_offset(uint32_t *data) { - if (ntohl(data[1]) != 0) { + if (data[1]) { /* 'attributes_follow' flag is TRUE, * so we have attributes on 21 dwords */ /* Skip unused values : -- 2.23.0.rc1

3 3

[U-Boot] [PATCH 1/1] env: net: U_BOOT_ENV_CALLBACKs should not depend on CMD_NET
by Heinrich Schuchardt 04 Sep '19

04 Sep '19

Some environment variables are relevant for networking. For these U_BOOT_ENV_CALLBACKs have been defined. When the corresponding environment variable is updated the callback updates the state of the network sub-system. In the UEFI subsystem we can use the network even if CONFIG_CMD_NET is not defined. Let the usage of the U_BOOT_ENV_CALLBACKs depend on CONFIG_NET and not on CONFIG_CMD_NET. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- Travis CI tested: https://travis-ci.org/xypron2/u-boot/builds/579439014 --- include/env_callback.h | 2 +- include/env_flags.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/env_callback.h b/include/env_callback.h index 982c07854d..74da20eec3 100644 --- a/include/env_callback.h +++ b/include/env_callback.h @@ -42,7 +42,7 @@ #define DNS_CALLBACK #endif -#ifdef CONFIG_CMD_NET +#ifdef CONFIG_NET #define NET_CALLBACKS \ "bootfile:bootfile," \ "ipaddr:ipaddr," \ diff --git a/include/env_flags.h b/include/env_flags.h index e5380f2948..725841a891 100644 --- a/include/env_flags.h +++ b/include/env_flags.h @@ -36,7 +36,7 @@ enum env_flags_varaccess { #define CONFIG_ENV_FLAGS_LIST_STATIC "" #endif -#ifdef CONFIG_CMD_NET +#ifdef CONFIG_NET #ifdef CONFIG_REGEX #define ETHADDR_WILDCARD "\\d*" #else -- 2.20.1

2 2

[U-Boot] [PATCH v2 5/5] CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at nfs_lookup_reply //RE: [PATCH 5/5] CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at nfs_lookup_reply
by liucheng (G) 04 Sep '19

04 Sep '19

Changes in v2: - Add reported-by tag for patch 5/5 -------------------------------------------------------------------------------------------------------------- CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at nfs_lookup_reply This patch adds a check to rpc_pkt.u.reply.data at nfs_lookup_reply. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> Reported-by: Fermín Serna <fermin(a)semmle.com> --- net/nfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/nfs.c b/net/nfs.c index 915acd9..89952ae 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -566,11 +566,15 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len) } if (supported_nfs_versions & NFSV2_FLAG) { + if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + NFS_FHSIZE) > len) + return -NFS_RPC_DROP; memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE); } else { /* NFSV3_FLAG */ filefh3_length = ntohl(rpc_pkt.u.reply.data[1]); if (filefh3_length > NFS3_FHSIZE) filefh3_length = NFS3_FHSIZE; + if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + filefh3_length) > len) + return -NFS_RPC_DROP; memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length); } -- 1.8.5.6 -----Original Message----- From: liucheng (G) Sent: Wednesday, August 21, 2019 10:48 PM To: u-boot(a)lists.denx.de Cc: liucheng (G) <liucheng32(a)huawei.com> Subject: [PATCH 5/5] CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at nfs_lookup_reply CVE-2019-14196: nfs: fix unbounded memcpy with a failed length check at nfs_lookup_reply This patch adds a check to rpc_pkt.u.reply.data at nfs_lookup_reply. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> --- net/nfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/nfs.c b/net/nfs.c index 915acd9..89952ae 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -566,11 +566,15 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len) } if (supported_nfs_versions & NFSV2_FLAG) { + if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + NFS_FHSIZE) > len) + return -NFS_RPC_DROP; memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE); } else { /* NFSV3_FLAG */ filefh3_length = ntohl(rpc_pkt.u.reply.data[1]); if (filefh3_length > NFS3_FHSIZE) filefh3_length = NFS3_FHSIZE; + if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + filefh3_length) > len) + return -NFS_RPC_DROP; memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length); } -- 1.8.5.6

2 2

[U-Boot] [PATCH v2 4/5] CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at nfs_readlink_reply //RE: [PATCH 4/5] CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at nfs_readlink_reply
by liucheng (G) 04 Sep '19

04 Sep '19

Changes in v2: - Add reported-by tag for patch 4/5 -------------------------------------------------------------------------------------------------------------- CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at nfs_readlink_reply This patch adds a check to rpc_pkt.u.reply.data at nfs_readlink_reply. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> Reported-by: Fermín Serna <fermin(a)semmle.com> --- net/nfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/nfs.c b/net/nfs.c index 11941fa..915acd9 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -634,6 +634,9 @@ static int nfs_readlink_reply(uchar *pkt, unsigned len) /* new path length */ rlen = ntohl(rpc_pkt.u.reply.data[1 + nfsv3_data_offset]); + if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + rlen) > len) + return -NFS_RPC_DROP; + if (*((char *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset])) != '/') { int pathlen; -- 1.8.5.6 -----Original Message----- From: liucheng (G) Sent: Wednesday, August 21, 2019 10:48 PM To: u-boot(a)lists.denx.de Cc: liucheng (G) <liucheng32(a)huawei.com> Subject: [PATCH 4/5] CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at nfs_readlink_reply CVE-2019-14195: nfs: fix unbounded memcpy with unvalidated length at nfs_readlink_reply This patch adds a check to rpc_pkt.u.reply.data at nfs_readlink_reply. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> --- net/nfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/nfs.c b/net/nfs.c index 11941fa..915acd9 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -634,6 +634,9 @@ static int nfs_readlink_reply(uchar *pkt, unsigned len) /* new path length */ rlen = ntohl(rpc_pkt.u.reply.data[1 + nfsv3_data_offset]); + if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + rlen) > len) + return -NFS_RPC_DROP; + if (*((char *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset])) != '/') { int pathlen; -- 1.8.5.6

2 2

[U-Boot] [PATCH v2 3/5] CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length check at nfs_read_reply //RE: [PATCH 3/5] CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length check at nfs_read_reply
by liucheng (G) 04 Sep '19

04 Sep '19

Changes in v2: - Add reported-by tag for patch 3/5 -------------------------------------------------------------------------------------------------------------- CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length check at nfs_read_reply This patch adds a check to rpc_pkt.u.reply.data at nfs_read_reply. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> Reported-by: Fermín Serna <fermin(a)semmle.com> --- net/nfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/nfs.c b/net/nfs.c index b7cf3b3..11941fa 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -701,6 +701,9 @@ static int nfs_read_reply(uchar *pkt, unsigned len) &(rpc_pkt.u.reply.data[4 + nfsv3_data_offset]); } + if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + rlen) > len) + return -9999; + if (store_block(data_ptr, nfs_offset, rlen)) return -9999; -- 1.8.5.6 -----Original Message----- From: liucheng (G) Sent: Wednesday, August 21, 2019 10:48 PM To: u-boot(a)lists.denx.de Cc: liucheng (G) <liucheng32(a)huawei.com> Subject: [PATCH 3/5] CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length check at nfs_read_reply CVE-2019-14194/CVE-2019-14198: nfs: fix unbounded memcpy with a failed length check at nfs_read_reply This patch adds a check to rpc_pkt.u.reply.data at nfs_read_reply. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> --- net/nfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/nfs.c b/net/nfs.c index b7cf3b3..11941fa 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -701,6 +701,9 @@ static int nfs_read_reply(uchar *pkt, unsigned len) &(rpc_pkt.u.reply.data[4 + nfsv3_data_offset]); } + if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + rlen) > len) + return -9999; + if (store_block(data_ptr, nfs_offset, rlen)) return -9999; -- 1.8.5.6

2 2

[U-Boot] [PATCH v2 2/5] CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper functions //RE: [PATCH 2/5] CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper functions
by liucheng (G) 04 Sep '19

04 Sep '19

Changes in v2: - Add reported-by tag for patch 2/5 -------------------------------------------------------------------------------------------------------------- CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper functions This patch adds a check to nfs_handler to fix buffer overflow for CVE-2019-14197, CVE-2019-14200, CVE-2019-14201, CVE-2019-14202, CVE-2019-14203 and CVE-2019-14204. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> Reported-by: Fermín Serna <fermin(a)semmle.com> --- net/nfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/nfs.c b/net/nfs.c index d6a7f8e..b7cf3b3 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -732,6 +732,9 @@ static void nfs_handler(uchar *pkt, unsigned dest, struct in_addr sip, debug("%s\n", __func__); + if (len > sizeof(struct rpc_t)) + return; + if (dest != nfs_our_port) return; -- 1.8.5.6 -----Original Message----- From: liucheng (G) Sent: Wednesday, August 21, 2019 10:48 PM To: u-boot(a)lists.denx.de Cc: liucheng (G) <liucheng32(a)huawei.com> Subject: [PATCH 2/5] CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper functions CVE: nfs: fix stack-based buffer overflow in some nfs_handler reply helper functions This patch adds a check to nfs_handler to fix buffer overflow for CVE-2019-14197, CVE-2019-14200, CVE-2019-14201, CVE-2019-14202, CVE-2019-14203 and CVE-2019-14204. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> --- net/nfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/nfs.c b/net/nfs.c index d6a7f8e..b7cf3b3 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -732,6 +732,9 @@ static void nfs_handler(uchar *pkt, unsigned dest, struct in_addr sip, debug("%s\n", __func__); + if (len > sizeof(struct rpc_t)) + return; + if (dest != nfs_our_port) return; -- 1.8.5.6

2 2

[U-Boot] [PATCH v2 1/5] CVE: net: fix unbounded memcpy of UDP packet//RE: [PATCH 1/5] CVE: net: fix unbounded memcpy of UDP packet
by liucheng (G) 04 Sep '19

04 Sep '19

Changes in v2: - Add reviewed-by and reported-by tags for patch 1/5 -------------------------------------------------------------------------------------------------------------- CVE: net: fix unbounded memcpy of UDP packet This patch adds a check to udp_len to fix unbounded memcpy for CVE-2019-14192, CVE-2019-14193 and CVE-2019-14199. Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt(a)gmail.com> Reported-by: Fermín Serna <fermin(a)semmle.com> --- net/net.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/net.c b/net/net.c index 40511db..68f9693 100644 --- a/net/net.c +++ b/net/net.c @@ -1253,6 +1253,9 @@ void net_process_received_packet(uchar *in_packet, int len) return; } + if (ntohs(ip->udp_len) < UDP_HDR_SIZE || ntohs(ip->udp_len) > ntohs(ip->ip_len)) + return; + debug_cond(DEBUG_DEV_PKT, "received UDP (to=%pI4, from=%pI4, len=%d)\n", &dst_ip, &src_ip, len); -- 1.8.5.6 -----Original Message----- From: Simon Goldschmidt [mailto:simon.k.r.goldschmidt@gmail.com] Sent: Thursday, August 22, 2019 3:30 AM To: liucheng (G) <liucheng32(a)huawei.com> Cc: U-Boot Mailing List <u-boot(a)lists.denx.de> Subject: Re: [U-Boot] [PATCH 1/5] CVE: net: fix unbounded memcpy of UDP packet On Wed, Aug 21, 2019 at 8:32 PM Cheng Liu <liucheng32(a)huawei.com> wrote: > > CVE: net: fix unbounded memcpy of UDP packet > > This patch adds a check to udp_len to fix unbounded memcpy for > CVE-2019-14192, CVE-2019-14193 and CVE-2019-14199. > > Signed-off-by: Cheng Liu <liucheng32(a)huawei.com> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt(a)gmail.com> Although being annoyed by the lack of response from Fermin nearly a month ago, would it make sense to add: Reported-by: Fermín Serna <fermin(a)semmle.com> Regards, Simon > --- > net/net.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/net.c b/net/net.c > index 40511db..68f9693 100644 > --- a/net/net.c > +++ b/net/net.c > @@ -1253,6 +1253,9 @@ void net_process_received_packet(uchar *in_packet, int len) > return; > } > > + if (ntohs(ip->udp_len) < UDP_HDR_SIZE || ntohs(ip->udp_len) > ntohs(ip->ip_len)) > + return; > + > debug_cond(DEBUG_DEV_PKT, > "received UDP (to=%pI4, from=%pI4, len=%d)\n", > &dst_ip, &src_ip, len); > -- > 1.8.5.6 > > _______________________________________________ > U-Boot mailing list > U-Boot(a)lists.denx.de > https://lists.denx.de/listinfo/u-boot

2 2