Re: EDAC list as Trojan Horse distribution ??

From: Hermann Ruckerbauer <Hermann.Ruckerbauer@EyeKnowHow.de>
To: He Zhe <zhe.he@windriver.com>,
	tony.luck@intel.com, bp@alien8.de, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, x86@kernel.org,
	linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: EDAC list as Trojan Horse distribution ??
Date: Tue, 16 Mar 2021 18:55:19 +0100	[thread overview]
Message-ID: <c0323578-9db6-74b0-ca6f-1324a2f1e9a1@EyeKnowHow.de> (raw)
In-Reply-To: <59d52031-f4e8-e754-c8b6-ca1130bf0cf1@EyeKnowHow.de>


> Hello *,
==> one more time as plain text.. 
>
>
> quite some tiem ago i sent a question to the EDAC list..
> I never receveived an answer.
>  
> today i got an answer with my original question quoted  and a .zip
> file attached:
>
> ======================================
>
> from:      nikolay.temizov@bpchargemaster.com
>
> Hello,
>
> Sorry, for my late reply to your question. Attached is the document
> you need.
>
> *Thank you*,
>
> ========================================
>
> I assume this is just to install a trojan horse when opening the
> attached zip (also I assume most of you will work on linux and it
> might not be a Problem for you anyhow   ;-) .
>
>  Virus total reports a Trojan horse, but only for with 2 out of 61
> virus scan engines (and I have to admit, I did not knew K7AntiVirus
> and Qihoo-360 before, all other engines reported the file as
> clean!!!!!!! ).
>
> So be careful when you get some feedback to old requests from this list
>
> Hermann
>
>
> -- 
> Our next Events:
>    Online Seminar: Open the Black Box of Memory
>        Date: 01.03 - 05.03.2021 (5 times 9:00 - 13:00) 
>
> EKH - EyeKnowHow 
> Signal Quality - Made in Bavaria
> Hermann Ruckerbauer
> www.EyeKnowHow.de
> Hermann.Ruckerbauer@EyeKnowHow.de
> Itzlinger Strasse 21a
> 94469 Deggendorf
> Tel.:	+49 (0)991 / 29 69 29 05
> Mobile:	+49 (0)176  / 787 787 77
> Fax:	+49 (0)991 / 98158793
> Hello,
>
>
>
>
>
> Am 16.04.2020 um 10:40 schrieb He Zhe:
>> Can this be considered for the moment?
>>
>> Thanks,
>> Zhe
>>
>> On 3/4/20 2:39 PM, zhe.he@windriver.com wrote:
>>> From: He Zhe <zhe.he@windriver.com>
>>>
>>> 32-bit user-space program would get errors like the following from ioctl
>>> syscall due to missing compat_ioctl.
>>> MCE_GET_RECORD_LEN: Inappropriate ioctl for device
>>>
>>> compat_ptr_ioctl is provided as a generic implementation of .compat_ioctl
>>> file operation to ioctl functions that either ignore the argument or pass
>>> a pointer to a compatible data type.
>>>
>>> Signed-off-by: He Zhe <zhe.he@windriver.com>
>>> ---
>>>  arch/x86/kernel/cpu/mce/dev-mcelog.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> index 7c8958d..6c9b91b7 100644
>>> --- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> +++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
>>> @@ -328,6 +328,7 @@ static const struct file_operations mce_chrdev_ops = {
>>>  	.write			= mce_chrdev_write,
>>>  	.poll			= mce_chrdev_poll,
>>>  	.unlocked_ioctl		= mce_chrdev_ioctl,
>>> +	.compat_ioctl		= compat_ptr_ioctl,
>>>  	.llseek			= no_llseek,
>>>  };
>>>  
>