From dev-return-57902-archive-asf-public=cust-asf.ponee.io@thrift.apache.org Sat Mar 7 10:18:03 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 4B84818066D for ; Sat, 7 Mar 2020 11:18:03 +0100 (CET) Received: (qmail 10331 invoked by uid 500); 7 Mar 2020 10:18:02 -0000 Mailing-List: contact dev-help@thrift.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@thrift.apache.org Delivered-To: mailing list dev@thrift.apache.org Received: (qmail 10319 invoked by uid 99); 7 Mar 2020 10:18:02 -0000 Received: from mailrelay1-us-west.apache.org (HELO mailrelay1-us-west.apache.org) (209.188.14.139) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 07 Mar 2020 10:18:02 +0000 Received: from jira-he-de.apache.org (static.172.67.40.188.clients.your-server.de [188.40.67.172]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 91700E30B6 for ; Sat, 7 Mar 2020 10:18:01 +0000 (UTC) Received: from jira-he-de.apache.org (localhost.localdomain [127.0.0.1]) by jira-he-de.apache.org (ASF Mail Server at jira-he-de.apache.org) with ESMTP id 3E6047822A0 for ; Sat, 7 Mar 2020 10:18:00 +0000 (UTC) Date: Sat, 7 Mar 2020 10:18:00 +0000 (UTC) From: "Jens Geyer (Jira)" To: dev@thrift.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (THRIFT-5131) i64 maxint decoding panics with integer-encoding >= 1.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/THRIFT-5131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Geyer resolved THRIFT-5131. -------------------------------- Fix Version/s: 0.14.0 Resolution: Fixed > i64 maxint decoding panics with integer-encoding >= 1.1.0 > --------------------------------------------------------- > > Key: THRIFT-5131 > URL: https://issues.apache.org/jira/browse/THRIFT-5131 > Project: Thrift > Issue Type: Sub-task > Components: Rust - Library > Affects Versions: 0.13.0 > Environment: % cargo --version --verbose > cargo 1.40.0 > release: 1.40.0 > % uname -a > Darwin Niks-MacBook-Pro.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64 i386 MacBookPro15,1 Darwin > Reporter: Nik Clayton > Assignee: Nik Clayton > Priority: Major > Labels: crash, encoding, thrift > Fix For: 0.14.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The Rust library for Thrift uses the integer-encoding crate. In version 1.1.0 (through at least 1.1.3, the most recent version) of this crate Thrift's usage appears to be responsible for a panic in the library when trying to decode i64 numbers in the range 0x4000_0000_0000_0000 to 0x7FFF_FFFF_FFFF_FFFF. > The integer-encoding crate does not panic when using it directly to encode / decode numbers in this range. > To see this, create a scratch crate with "cargo new int_encoding". > Replace the contents of Cargo.toml with the following: > {code} > [package] > name = "int_encoding" > version = "0.1.0" > authors = ["Nik Clayton "] > edition = "2018" > [dependencies] > thrift = "0.13.0" > integer-encoding = "=1.0.8" > {code} > This pins the integer-encoding library to version 1.0.8. > Put the following in src/main.rs: > {code} > use thrift::protocol::{ > TCompactInputProtocol, TCompactOutputProtocol, TFieldIdentifier, TInputProtocol, > TOutputProtocol, TType, > }; > use integer_encoding::*; > fn main() { > let mut field_value = i64::max_value(); // Fails > // Uncomment the next line to see success > //field_value = (1i64 << 62) - 1; > let mut buf; > println!("Value is: {}, {:X}", field_value, field_value); > // First check that encoding and decoding works using the integer_encoding > // library directly. > buf = field_value.encode_var_vec(); > let (val, _) = VarInt::decode_var(&buf[..]); > assert_eq!(field_value, val); > // Clear the buffer, and try encoding the same value using Thrift. This code > // is almost identical to https://docs.rs/thrift/0.13.0/thrift/protocol/index.html > // except that (a) it's an I64, and (b) the channel is a Vec. > buf.clear(); > let mut out_protocol = TCompactOutputProtocol::new(&mut buf); > out_protocol > .write_field_begin(&TFieldIdentifier::new( > "max_int", > TType::I64, > 1, > )) > .unwrap(); > out_protocol.write_i64(field_value).unwrap(); > out_protocol.write_field_end().unwrap(); > out_protocol.flush().unwrap(); > let mut in_protocol = TCompactInputProtocol::new(&buf[..]); > in_protocol.read_field_begin().unwrap(); > assert_eq!(field_value, in_protocol.read_i64().unwrap()); > in_protocol.read_field_end().unwrap(); > } > {code} > Run this with "cargo run", it should succeed, and print: > {code} > Value is: 9223372036854775807, 7FFFFFFFFFFFFFFF > {code} > Edit Cargo.toml and change the "integer-encoding" line to > {code} > integer-encoding = "=1.1.3" > {code} > Run with "RUST_BACKTRACE=1 cargo run" and you will see the following panic (I've elided the full panic here): > {code} > thread 'main' panicked at 'index 11 out of range for slice of length 10', src/libcore/slice/mod.rs:2664:5 > stack backtrace: > [...] > 13: integer_encoding::reader::VarIntProcessor::decode > at /Users/nik/d/rs/.cargo-home/registry/src/github.com-1ecc6299db9ec823/integer-encoding-1.1.3/src/reader.rs:56 > 14: ::read_varint > at /Users/nik/d/rs/.cargo-home/registry/src/github.com-1ecc6299db9ec823/integer-encoding-1.1.3/src/reader.rs:104 > 15: as thrift::protocol::TInputProtocol>::read_i64 > at /Users/nik/d/rs/.cargo-home/registry/src/github.com-1ecc6299db9ec823/thrift-0.13.0/src/protocol/compact.rs:246 > 16: int_encoding::main > at src/main.rs:41 > [...] > {code} > As you can see, the panic is coming from the call to Thrift's read_i64(). The earlier code that used integer-encoding directly did not panic. That's why I think the problem is somewhere in Thrift. > If you edit main.rs and uncomment the line > {code} > //field_value = (1i64 << 62) - 1; > {code} > the panic disappears. I believe this is the largest number that can be used without triggering the panic. -- This message was sent by Atlassian Jira (v8.3.4#803005)