[OE-core] [PATCH] file: remove the original magic.h
Junling Zheng
zhengjunling at huawei.com
Sat Mar 28 09:37:19 UTC 2015
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 at Patch-Test:file-5.14>0$ diff -u src/magic.h src/magic.h
>> magic.h magic.h.in
>> z00238152 at 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
More information about the Openembedded-core
mailing list