lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160425134446.GA6523@quack2.suse.cz>
Date:	Mon, 25 Apr 2016 15:44:46 +0200
From:	Jan Kara <jack@...e.cz>
To:	Andrew Gabbasov <andrew_gabbasov@...tor.com>
Cc:	Jan Kara <jack@...e.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] udf: Fix conversion of 'dstring' fields to UTF8

On Mon 25-04-16 06:19:38, Andrew Gabbasov wrote:
> Commit 9293fcfbc1812a22ad5ce1b542eb90c1bbe01be1
> ("udf: Remove struct ustr as non-needed intermediate storage"),
> while getting rid of 'struct ustr', does not take any special care
> of 'dstring' fields and effectively use fixed field length instead
> of actual string length, encoded in the last byte of the field.
> 
> Also, commit 484a10f49387e4386bf2708532e75bf78ffea2cb
> ("udf: Merge linux specific translation into CS0 conversion function")
> introduced checking of the length of the string being converted,
> requiring proper alignment to number of bytes constituing each
> character.
> 
> The UDF volume identifier is represented as a 32-bytes 'dstring',
> and needs to be converted from CS0 to UTF8, while mounting UDF
> filesystem. The changes in mentioned commits can in some cases
> lead to incorrect handling of volume identifier:
> - if the actual string in 'dstring' is of maximal length and
> does not have zero bytes separating it from dstring encoded
> length in last byte, that last byte may be included in conversion,
> thus making incorrect resulting string;
> - if the identifier is encoded with 2-bytes characters (compression
> code is 16), the length of 31 bytes (32 bytes of field length minus
> 1 byte of compression code), taken as the string length, is reported
> as an incorrect (unaligned) length, and the conversion fails, which
> in its turn leads to volume mounting failure.
> 
> This patch introduces handling of 'dstring' encoded length field
> in udf_CS0toUTF8 function, that is used in all and only cases
> when 'dstring' fields are converted. Currently these cases are
> processing of Volume Identifier and Volume Set Identifier fields.
> The function is also renamed to udf_dstrCS0toUTF8 to distinctly
> indicate that it handles 'dstring' input.

Thanks. I've merged the patch to my tree.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ