From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) by sourceware.org (Postfix) with ESMTPS id 488E73858C27 for ; Fri, 5 Nov 2021 14:30:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 488E73858C27 Received: by mail-oo1-xc2a.google.com with SMTP id q39-20020a4a962a000000b002b8bb100791so3093206ooi.0 for ; Fri, 05 Nov 2021 07:30:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=m/8luh4BwUDaIreE9RC8ANE1A6jDMcLRLqT+poBQ7Xw=; b=g9rCyynabI3T4QRJAAicI+O8Vna6FZhRDnkJATEOEPiggFt+hg/wOqQ9l6Jez482F6 FZBR3582AHd5KARHyxXSrHJ39xwZjH0lsAk0OzfyU3P9SU+GskQsSF1eH78Lqg3yA7/G 9q0BLAtoHj01yPpn9/lqqpTFK/EeyiiPDiMTKtEqnGbYRNgeUmnHGlLkWx17DBD52EUn sqYKokTFlWnatkbIV43h6lKx/AKXCngqSKgkKE3tKNxp19ECeXQa+lajflrERGZqXPrK hAa9sMHuD9NFqRT/4IFFYREtkCMEDGV/hpx9RqzLJOeICNeUk9TyVKo2nINjylve2QZ4 KsZw== X-Gm-Message-State: AOAM531hiATaRQY4rZvREuEjIn4ZGFqqQLcXW0xomWjNdkcL9OzVd9DQ TdhF1tlzf5Rmtc24iGBmbW+PUg== X-Google-Smtp-Source: ABdhPJxM1EJ6SobeadkeIL62HL+IrbdQtQszuhO6RtrRtmYQR4qYE2jnRUM7RjCecl7IDgA1FyICyw== X-Received: by 2002:a4a:4994:: with SMTP id z142mr8998305ooa.39.1636122632607; Fri, 05 Nov 2021 07:30:32 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:55a:c916:e574:3d13:f60c? ([2804:431:c7cb:55a:c916:e574:3d13:f60c]) by smtp.gmail.com with ESMTPSA id y192sm2083206oie.21.2021.11.05.07.30.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Nov 2021 07:30:32 -0700 (PDT) Message-ID: Date: Fri, 5 Nov 2021 11:30:30 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: [PATCH 2/2] elf: Detect PT_LOAD segments that extend beyond EOF and refuse loading Content-Language: en-US To: Florian Weimer , libc-alpha@sourceware.org References: <27f078539ae2a5b390705ac6fa1a7437ae8ce97c.1636120354.git.fweimer@redhat.com> From: Adhemerval Zanella In-Reply-To: <27f078539ae2a5b390705ac6fa1a7437ae8ce97c.1636120354.git.fweimer@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Nov 2021 14:30:38 -0000 On 05/11/2021 10:59, Florian Weimer via Libc-alpha wrote: > @@ -1177,6 +1178,17 @@ _dl_map_object_from_fd (const char *name, const char *origname, int fd, > = N_("ELF load command address/offset not properly aligned"); > goto lose; > } > + if (__glibc_unlikely (ph->p_offset + ph->p_filesz > file_size)) > + { > + /* If the segment is not fully backed by the file, > + accessing memory beyond the last full page results in > + SIGBUS. This often happens with non-loadable ELF > + objects containing separated debugging information > + (which have load segments that match the original ELF > + file). */ > + errstring = N_("ELF load command past end of file"); > + goto lose; > + } Are these still valid objects? How does this object are created exactly? You state that it happens with 'some toolchain versions', is this something new or has it be fixed (if it is an issue) upstream?