All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junling Zheng <zhengjunling@huawei.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: "peifeiyue@huawei.com" <peifeiyue@huawei.com>,
	OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] file: remove the original magic.h
Date: Sat, 28 Mar 2015 17:37:19 +0800	[thread overview]
Message-ID: <5516764F.8050805@huawei.com> (raw)
In-Reply-To: <1427532804.14020.220.camel@linuxfoundation.org>

On 2015/3/28 16:53, Richard Purdie wrote:
> On Sat, 2015-03-28 at 10:36 +0800, Junling Zheng wrote:
>> I backport some commits from upstream to fix CVE-2014-9620, and some of them involve the modifying of magic.h.in:
>>
>> 90018fe22ff8b74a22fcd142225b0a00f3f12677
>> 6ce24f35cd4a43c4bdd249e8e0c4952c1f8eac67
>> 0056ec32255de1de973574b0300161a1568767d6
>> 09e41625c999a2e5b51e1092f0ef2432a99b5c33
>> ce90e05774dd77d86cfc8dfa6da57b32816841c4
>>
>> And the final difference between magic.h and magic.h.in is:
>>
>> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h
>> magic.h     magic.h.in
>> z00238152@Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h.in
>> --- src/magic.h	2015-03-28 02:01:46.000000000 +0000
>> +++ src/magic.h.in	2015-03-28 02:01:47.000000000 +0000
>> @@ -74,7 +74,7 @@
>>  #define	MAGIC_NO_CHECK_FORTRAN	0x000000 /* Don't check ascii/fortran */
>>  #define	MAGIC_NO_CHECK_TROFF	0x000000 /* Don't check ascii/troff */
>>
>> -#define MAGIC_VERSION		514	/* This implementation */
>> +#define MAGIC_VERSION		X.YY	/* This implementation */
>>
>>
>>  #ifdef __cplusplus
>> @@ -100,7 +100,12 @@
>>  int magic_list(magic_t, const char *);
>>  int magic_errno(magic_t);
>>
>> -#define MAGIC_PARAM_MAX_RECURSION	0
>> +#define MAGIC_PARAM_INDIR_MAX		0
>> +#define MAGIC_PARAM_NAME_MAX		1
>> +#define MAGIC_PARAM_ELF_PHNUM_MAX	2
>> +#define MAGIC_PARAM_ELF_SHNUM_MAX	3
>> +#define MAGIC_PARAM_ELF_NOTES_MAX	4
>> +
>>  int magic_setparam(magic_t, int, const void *);
>>  int magic_getparam(magic_t, int, void *);
>>
>>
>> So, if Makefile doesn't generate a new magic.h, there will be some "symbol undeclared" errors during compiling.
>>
>> By the way, the upstream code has only magic.h.in, and no magic.h, which only exists in release version tarballs.
>>
>> And I think the original magic.h is redundant.
> 
> We ran into this problem in our branches. You need to ensure that your
> CVE patches just touch magic.h.in and *not* magic.h. If you do that, the
> timestamp of magic.h.in will be more recent that magic.h and your build
> will function correctly.
> 
> The problem is that patch can patch those two files "at the same time"
> on fast machines. You should never patch generated filed in patches in
> OE in general.
> 
> Cheers,
> 
> Richard
>
Hi, Richard

You're right. My CVE patches indeed touch the original magic.h, and that's also why this problem reproduces probabilistic.

I remove the modifying of magic.h in my patches, and this problem seems to be fixed.

However, I still think the origin magic.h is confusing and redundant...:)

Thanks,

Junling



  reply	other threads:[~2015-03-28  9:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26  9:18 [PATCH] file: remove the original magic.h Junling Zheng
2015-03-26  9:54 ` Richard Purdie
2015-03-26 11:31   ` Junling Zheng
2015-03-26 11:58     ` Jack Mitchell
2015-03-26 12:58       ` Junling Zheng
2015-03-26 13:08         ` Burton, Ross
2015-03-27  3:31           ` Junling Zheng
2015-03-27  9:56             ` Burton, Ross
2015-03-28  2:36               ` Junling Zheng
2015-03-28  8:53                 ` Richard Purdie
2015-03-28  9:37                   ` Junling Zheng [this message]
2015-03-28 11:05                     ` Richard Purdie
2015-03-30  1:49                       ` Junling Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5516764F.8050805@huawei.com \
    --to=zhengjunling@huawei.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peifeiyue@huawei.com \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.