Hi Greg,
This has been applied to 4.19-stable, but should be needed in 4.14-stable also. I have attached the backported patch and have also tested with one such DVD where the problem was seen.
-- Regards Sudip
Hi,
On Tue 04-12-18 20:53:47, Sudip Mukherjee wrote:
This has been applied to 4.19-stable, but should be needed in 4.14-stable also. I have attached the backported patch and have also tested with one such DVD where the problem was seen.
Thanks for the backport. I actually didn't get a message that application of this patch to 4.14-stable would fail so probably it is just waiting in Greg's queue. Anyway the patch looks good to me.
Honza
-- Regards Sudip
From 197a1e1728bb1aab5a2e747a04ecd90390b1d8b7 Mon Sep 17 00:00:00 2001 From: Jan Kara jack@suse.cz Date: Fri, 16 Nov 2018 13:43:17 +0100 Subject: [PATCH] udf: Allow mounting volumes with incorrect identification strings
commit b54e41f5efcb4316b2f30b30c2535cc194270373 upstream.
Commit c26f6c615788 ("udf: Fix conversion of 'dstring' fields to UTF8") started to be more strict when checking whether converted strings are properly formatted. Sudip reports that there are DVDs where the volume identification string is actually too long - UDF reports:
[ 632.309320] UDF-fs: incorrect dstring lengths (32/32)
during mount and fails the mount. This is mostly harmless failure as we don't need volume identification (and even less volume set identification) for anything. So just truncate the volume identification string if it is too long and replace it with 'Invalid' if we just cannot convert it for other reasons. This keeps slightly incorrect media still mountable.
CC: stable@vger.kernel.org Fixes: c26f6c615788 ("udf: Fix conversion of 'dstring' fields to UTF8") Reported-and-tested-by: Sudip Mukherjee sudipm.mukherjee@gmail.com Signed-off-by: Jan Kara jack@suse.cz Signed-off-by: Sudip Mukherjee sudipm.mukherjee@gmail.com
fs/udf/super.c | 16 ++++++++++------ fs/udf/unicode.c | 14 +++++++++++--- 2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c index 9b0d6562d0a1..242d960df9a1 100644 --- a/fs/udf/super.c +++ b/fs/udf/super.c @@ -922,16 +922,20 @@ static int udf_load_pvoldesc(struct super_block *sb, sector_t block) } ret = udf_dstrCS0toUTF8(outstr, 31, pvoldesc->volIdent, 32);
- if (ret < 0)
goto out_bh;
- strncpy(UDF_SB(sb)->s_volume_ident, outstr, ret);
- if (ret < 0) {
strcpy(UDF_SB(sb)->s_volume_ident, "InvalidName");
pr_warn("incorrect volume identification, setting to "
"'InvalidName'\n");
- } else {
strncpy(UDF_SB(sb)->s_volume_ident, outstr, ret);
- } udf_debug("volIdent[] = '%s'\n", UDF_SB(sb)->s_volume_ident);
ret = udf_dstrCS0toUTF8(outstr, 127, pvoldesc->volSetIdent, 128);
- if (ret < 0)
- if (ret < 0) {
goto out_bh;ret = 0;
- } outstr[ret] = 0; udf_debug("volSetIdent[] = '%s'\n", outstr);
diff --git a/fs/udf/unicode.c b/fs/udf/unicode.c index 3a3be23689b3..61a1738895b7 100644 --- a/fs/udf/unicode.c +++ b/fs/udf/unicode.c @@ -341,6 +341,11 @@ static int udf_name_to_CS0(uint8_t *ocu, int ocu_max_len, return u_len; } +/*
- Convert CS0 dstring to output charset. Warning: This function may truncate
- input string if it is too long as it is used for informational strings only
- and it is better to truncate the string than to refuse mounting a media.
- */
int udf_dstrCS0toUTF8(uint8_t *utf_o, int o_len, const uint8_t *ocu_i, int i_len) { @@ -349,9 +354,12 @@ int udf_dstrCS0toUTF8(uint8_t *utf_o, int o_len, if (i_len > 0) { s_len = ocu_i[i_len - 1]; if (s_len >= i_len) {
pr_err("incorrect dstring lengths (%d/%d)\n",
s_len, i_len);
return -EINVAL;
pr_warn("incorrect dstring lengths (%d/%d),"
" truncating\n", s_len, i_len);
s_len = i_len - 1;
/* 2-byte encoding? Need to round properly... */
if (ocu_i[0] == 16)
} }s_len -= (s_len - 1) & 2;
2.11.0
On Wed, Dec 5, 2018 at 11:30 AM Jan Kara jack@suse.cz wrote:
Hi,
On Tue 04-12-18 20:53:47, Sudip Mukherjee wrote:
This has been applied to 4.19-stable, but should be needed in 4.14-stable also. I have attached the backported patch and have also tested with one such DVD where the problem was seen.
Thanks for the backport. I actually didn't get a message that application of this patch to 4.14-stable would fail so probably it is just waiting in Greg's queue. Anyway the patch looks good to me.
I was also wondering about that. But usually Greg's script will try the commits marked for stable on all the LTS kernels at the same time. So since it is applied to 4.19-stable, his script should have already tried in 4.14-stable (unless he has changed his scripts after last time I saw it).
On Wed, Dec 05, 2018 at 11:54:10AM +0000, Sudip Mukherjee wrote:
On Wed, Dec 5, 2018 at 11:30 AM Jan Kara jack@suse.cz wrote:
Hi,
On Tue 04-12-18 20:53:47, Sudip Mukherjee wrote:
This has been applied to 4.19-stable, but should be needed in 4.14-stable also. I have attached the backported patch and have also tested with one such DVD where the problem was seen.
Thanks for the backport. I actually didn't get a message that application of this patch to 4.14-stable would fail so probably it is just waiting in Greg's queue. Anyway the patch looks good to me.
I was also wondering about that. But usually Greg's script will try the commits marked for stable on all the LTS kernels at the same time. So since it is applied to 4.19-stable, his script should have already tried in 4.14-stable (unless he has changed his scripts after last time I saw it).
I don't know what went wrong here, my fault, sorry.
Yes, this didn't apply to the older kernels and it should have triggered an email from me.
greg k-h
On Tue, Dec 04, 2018 at 08:53:47PM +0000, Sudip Mukherjee wrote:
Hi Greg,
This has been applied to 4.19-stable, but should be needed in 4.14-stable also. I have attached the backported patch and have also tested with one such DVD where the problem was seen.
Now queued up to 4.14.y and 4.9.y, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org