[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