On 4/22/24 18:41, Bui Quang Minh wrote:
Currently, we allocate a count-sized kernel buffer and copy count bytes
from userspace to that buffer. Later, we use sscanf on this buffer but we
don't ensure that the string is terminated inside the buffer, this can lead
to OOB read when using sscanf. Fix
From: Paolo Abeni
Sabrina reports that the igb driver does not cope well with large
MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
corruption on TX.
The root cause of the issue is that the driver does not take into
account properly the (possibly large) shared info size when selec
During successful probe, igc logs this:
[5.133667] igc :01:00.0 (unnamed net_device) (uninitialized): PHC added
The reason is that igc_ptp_init() is called very early, even before
register_netdev() has been called. So the
On 22.04.2024 18:41, Bui Quang Minh wrote:
> Hi everyone,
>
> I found that some drivers contains an out-of-bound read pattern like this
>
> kern_buf = memdup_user(user_buf, count);
> ...
> sscanf(kern_buf, ...);
>
> The sscanf can be replaced by some other string-related fun
On 4/23/24 13:10, Marcin Szycik wrote:
On 22.04.2024 18:41, Bui Quang Minh wrote:
Hi everyone,
I found that some drivers contains an out-of-bound read pattern like this
kern_buf = memdup_user(user_buf, count);
...
sscanf(kern_buf, ...);
The sscanf can be replaced by
Tue, Apr 23, 2024 at 12:24:46PM CEST, vinsc...@redhat.com wrote:
>From: Paolo Abeni
>
>Sabrina reports that the igb driver does not cope well with large
>MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
>corruption on TX.
>
>The root cause of the issue is that the driver does not tak
Tue, Apr 23, 2024 at 12:24:46PM CEST, vinsc...@redhat.com wrote:
>From: Paolo Abeni
>
>Sabrina reports that the igb driver does not cope well with large
>MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
>corruption on TX.
>
>The root cause of the issue is that the driver does not tak
Tue, Apr 23, 2024 at 11:14:59AM CEST, sergey.temerkha...@intel.com wrote:
>Include segment/domain number in the device name to distinguish
>between PCI devices located on different root complexes in
>multi-segment configurations. Naming is changed from
>ptp___clk to ptpclk
I don't understand
Dear Corinna,
Thank you for the patch.
Am 23.04.24 um 12:24 schrieb Corinna Vinschen:
From: Paolo Abeni
It’d be great if you removed the trailing dot/period in the commit
message summary.
Sabrina reports that the igb driver does not cope well with large
MAX_SKB_FRAG values: setting MAX
Tue, Apr 23, 2024 at 01:56:55PM CEST, sergey.temerkha...@intel.com wrote:
>
>
>> -Original Message-
>> From: Jiri Pirko
>> Sent: Tuesday, April 23, 2024 1:36 PM
>> To: Temerkhanov, Sergey
>> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Kitszel,
>> Przemyslaw
>> Subject:
From: Paolo Abeni
Sabrina reports that the igb driver does not cope well with large
MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
corruption on TX.
An easy reproducer is to run ssh to connect to the machine. With
MAX_SKB_FRAGS=17 it works, with MAX_SKB_FRAGS=45 it fails.
The r
Hi Paul,
On Apr 23 13:52, Paul Menzel wrote:
> Dear Corinna,
>
>
> Thank you for the patch.
>
>
> Am 23.04.24 um 12:24 schrieb Corinna Vinschen:
> > From: Paolo Abeni
>
> It’d be great if you removed the trailing dot/period in the commit message
> summary.
>
> > Sabrina reports that the igb
allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240423 gcc
arc randconfig-002-20240423 gcc
arm
Hi Jiri,
On Apr 23 13:26, Jiri Pirko wrote:
> Tue, Apr 23, 2024 at 12:24:46PM CEST, vinsc...@redhat.com wrote:
> >From: Paolo Abeni
> >
> >Sabrina reports that the igb driver does not cope well with large
> >MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
> >corruption on TX.
> >
>
On Tue, Apr 23, 2024 at 3:47 PM Corinna Vinschen wrote:
>
> From: Paolo Abeni
>
> Sabrina reports that the igb driver does not cope well with large
> MAX_SKB_FRAG values: setting MAX_SKB_FRAG to 45 causes payload
> corruption on TX.
>
> An easy reproducer is to run ssh to connect to the machine.
From: Michal Swiatkowski
ice_clear_dflt_vsi() is only removing default rule. Both default RX and
TX rule should be removed during release.
If it isn't switching to switchdev, second time results in error, because
TX filter is already there.
Fix it by removing the correct set of rules.
Fixes: 5
PCI_HEADER_TYPE_MULTIFUNC is define by e1000e and ixgbe and both are
unused. There is already PCI_HEADER_TYPE_MFD in pci_regs.h anyway which
should be used instead so remove the duplicated defines of it.
Signed-off-by: Ilpo Järvinen
---
drivers/net/ethernet/intel/e1000e/defines.h | 2 --
drive
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240423 gcc
arc randconfig-002-20240423 gcc
arm
The patch fixes an issue when repeated EEH reports with a single error
on the bus of Intel X710 4-port 10G Base-T adapter, in the MSI domain
causing the devices to be permanently disabled. It fully resets and
restart the devices when handling the PCI EEH error.
Two new functions, i40e_io_suspend(
On Mon, Apr 22, 2024 at 11:41:40PM +0700, Bui Quang Minh wrote:
> Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
> userspace to that buffer. Later, we use scanf on this buffer but we don't
> ensure that the string is terminated inside the buffer, this can lead to
> OOB read wh
Include segment/domain number in the device name to distinguish
between PCI devices located on different root complexes in
multi-segment configurations. Naming is changed from
ptp___clk to ptpclk
v1->v2
Rebase on top of the latest changes
Signed-off-by: Sergey Temerkhanov
Reviewed-by: Przem
> -Original Message-
> From: Mateusz Polchlopek
> Sent: Thursday, April 18, 2024 10:55 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; ho...@kernel.org; anthony.l.ngu...@intel.com;
> Jacob Keller ; Wojciech Drewek
> ; Mateusz Polchlopek
>
> Subject: [EXTERNAL] [
> -Original Message-
> From: Mateusz Polchlopek
> Sent: Thursday, April 18, 2024 10:55 AM
> To: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org; ho...@kernel.org; anthony.l.ngu...@intel.com;
> Jacob Keller ; Wojciech Drewek
> ; Mateusz Polchlopek
>
> Subject: [EXTERNAL] [
> During successful probe, igc logs this:
>
> [5.133667] igc :01:00.0 (unnamed net_device) (uninitialized): PHC
> added
>
> The reason is that igc_ptp_init() is called very early, even before
> register_netdev() has be
From: Ngai-Mint Kwan
Getting coalesce settings while reset is in progress can cause NULL
pointer deference bug.
If under reset, abort get coalesce for ethtool.
Fixes: 67fe64d78c43 ("ice: Implement getting and setting ethtool coalesce")
Signed-off-by: Ngai-Mint Kwan
Reviewed-by: Mateusz Polchlop
> -Original Message-
> From: Jiri Pirko
> Sent: Tuesday, April 23, 2024 1:36 PM
> To: Temerkhanov, Sergey
> Cc: intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; Kitszel,
> Przemyslaw
> Subject: Re: [PATCH iwl-next v2] ice: Extend auxbus device naming
>
> Tue, Apr 23, 2024 at
On 4/23/24 13:50, Heiko Carstens wrote:
On Mon, Apr 22, 2024 at 11:41:40PM +0700, Bui Quang Minh wrote:
Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
userspace to that buffer. Later, we use scanf on this buffer but we don't
ensure that the string is terminated inside the b
Tue, Apr 23, 2024 at 03:54:05PM CEST, vinsc...@redhat.com wrote:
>Hi Jiri,
>
>On Apr 23 13:26, Jiri Pirko wrote:
>> Tue, Apr 23, 2024 at 12:24:46PM CEST, vinsc...@redhat.com wrote:
>> >From: Paolo Abeni
>> >
>> >Sabrina reports that the igb driver does not cope well with large
>> >MAX_SKB_FRAG val
On Fri, Apr 19, 2024 at 12:20:05PM -0400, Jérôme Carretero wrote:
> Hi Sasha,
>
>
> Thank you, sorry for the delay but I coudln't reboot.
>
> Adding Greg KH because I don't know if stable will receive my e-mail
> (not subscribed) but the regression was integrated in stable:
> commit 0a4e3c2d976
allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240423 gcc
arc randconfig-002-20240423 gcc
arm
allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20240423 gcc
arc randconfig-002
On 4/23/2024 6:14 AM, Jiri Pirko wrote:
> Tue, Apr 23, 2024 at 01:56:55PM CEST, sergey.temerkha...@intel.com wrote:
>>
>>
>>> -Original Message-
>>> From: Jiri Pirko
>>> Sent: Tuesday, April 23, 2024 1:36 PM
>>> To: Temerkhanov, Sergey
>>> Cc: intel-wired-...@lists.osuosl.org; net...@v
On 17/04/2024 22:03, Lifshits, Vitaly wrote:
This is a partial revert of commit 6dbdd4de0362 ("e1000e: Workaround
for sporadic MDI error on Meteor Lake systems"). The referenced commit
introduced an issue on vPro systems, where disconnecting and reconnecting
the LAN cable might result in a kernel
33 matches
Mail list logo
