linux-kernel - Re: [Intel-wired-lan] [PATCH v2] e1000: fix OOB in e1000_tbi_should

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANUHTR9o-wzkSzYeRwQvu-MEdYXQ4tbNXvDD2WyCfA1MGCG=Bw@mail.gmail.com>
Date: Tue, 2 Dec 2025 19:34:12 +0800
From: Guangshuo Li <lgs201920130244@...il.com>
To: Paul Menzel <pmenzel@...gen.mpg.de>
Cc: Jesse Brandeburg <jesse.brandeburg@...el.com>, Tony Nguyen <anthony.l.nguyen@...el.com>, 
	"David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Florian Westphal <fw@...len.de>, Jeff Kirsher <jeffrey.t.kirsher@...el.com>, 
	intel-wired-lan@...ts.osuosl.org, netdev@...r.kernel.org, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org, 
	Tony Nguyen <tony.nguyen@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH v2] e1000: fix OOB in e1000_tbi_should_accept()

Hi Paul,

thanks for your comments.

----Do you have reproducer to forth an invalid length?

Yes. The issue is reproducible with a concrete system call sequence.

I am running on top of a fuzzer called PrIntFuzz, which is built on
syzkaller. PrIntFuzz adds a custom syscall syz_prepare_data() that is
used to simulate device input. In other words, the device side traffic
is not coming from a real hardware device, but is deliberately
constructed by the fuzzer through syz_prepare_data().

The exact reproducer is provided in the attached syzkaller program
(system call sequence) generated by PrIntFuzz, which consistently
triggers the invalid length and the crash on my setup.

(The attached program is exactly the sequence I am running to
reproduce the problem.)

----Should an error be logged, or is it a common scenario, that such
traffic exists?

In normal deployments, I don’t expect such traffic from a well-behaved
I2C device. In my case, the malformed length only appears because
PrIntFuzz is intentionally crafting invalid inputs and feeding them to
the driver via syz_prepare_data(). So this is not a “common” or
expected scenario in real-world use, but it is a realistic
attacker/fuzzer scenario, since the length field can be controlled by
an external peer/device.

Given that, I think the driver should treat an invalid length as an
error and fail the request instead of trusting it and risking memory
corruption.

Regarding logging, I’m fully open to your preference. From my point of
view, logging this as an error seems reasonable, because it indicates
malformed or buggy input from the device side. However, if you expect
this condition might occur more frequently in practice and would
prefer to reduce noise, I can switch it to dev_dbg() or even drop the
log entirely.

Please let me know which logging level you would prefer, and I will
update the patch accordingly.

Best regards,
Guangshuo Li

View attachment "reproducer.txt" of type "text/plain" (52792 bytes)