Bug#902740: initramfs-tools: /etc/initramfs-tools/conf.d/resume not updated with dpkg-reconfigure initramfs-tools

[tom]

Package: initramfs-tools
Version: 0.130
Severity: wishlist

I copied a drive from one laptop to another, using
rsync and various hacks. The swap partition on the new drive
has a different UUID. 

I had to regenerate initramfs for each kernel version,
because the lappies are different type hardware, with 
different modules needed.

When I ran update-initramfs it worked perfectly, except that 
it threw an informational message that it couldn't find the
resume partition listed in the conf file, so it would use
the swap partition it did find.

I ran dpkg-reconfigure initramfs-tools to update the 
configs with the new swap partition UUID, but the message 
kept appearing.

So, rather than have it keep throwing the informational
message forever, I copied and pasted the UUID of swap
into /etc/initramfs-tools/conf.d/resume.

It works now without the message. It would be nice if
the message gave the path of the config file in question,
or better yet, if dpkg-reconfigure initramfs-tools
 would update the 'resume' config file with the new
swap partition. 

-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 18M Feb 27 00:37 /boot/initrd.img-4.9.0-4-amd64
-rw-r--r-- 1 root root 18M May 17 21:08 /boot/initrd.img-4.9.0-6-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.9.0-6-amd64 
root=UUID=a28a1d13-49b8-4f25-b310-d1d17e69cec9 ro quiet

-- resume
RESUME=UUID=31fe945f-b629-425b-91dd-e08260816714
-- /proc/filesystems
ext3
ext2
ext4
xfs
fuseblk
vfat

-- lsmod
Module  Size  Used by
tun28672  0
nls_ascii  16384  0
nls_cp437  20480  0
vfat   20480  0
fat69632  1 vfat
fuse   98304  3
ftdi_sio   53248  0
usbserial  49152  1 ftdi_sio
pci_stub   16384  1
vboxpci24576  0
vboxnetadp 28672  0
vboxnetflt 28672  0
vboxdrv   466944  3 vboxnetadp,vboxnetflt,vboxpci
xfs  1224704  2
libcrc32c  16384  1 xfs
usblp  20480  0
uas24576  0
usb_storage73728  3 uas
hid_generic16384  0
usbhid 53248  0
hid   122880  2 hid_generic,usbhid
intel_rapl 20480  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
asus_nb_wmi28672  0
asus_wmi   28672  1 asus_nb_wmi
sparse_keymap  16384  1 asus_wmi
rfkill 24576  3 asus_wmi
kvm_intel 192512  0
kvm   593920  1 kvm_intel
snd_hda_codec_hdmi 49152  1
iTCO_wdt   16384  0
irqbypass  16384  1 kvm
iTCO_vendor_support16384  1 iTCO_wdt
crct10dif_pclmul   16384  0
crc32_pclmul   16384  0
snd_hda_codec_realtek90112  1
ghash_clmulni_intel16384  0
snd_hda_codec_generic69632  1 snd_hda_codec_realtek
nouveau  1556480  1
i915 1257472  17
intel_cstate   16384  0
snd_hda_intel  36864  6
mxm_wmi16384  1 nouveau
intel_uncore  118784  0
snd_hda_codec 135168  4 
snd_hda_intel,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
ttm98304  1 nouveau
evdev  24576  19
joydev 20480  0
intel_rapl_perf16384  0
snd_hda_core   86016  5 
snd_hda_intel,snd_hda_codec,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek
drm_kms_helper155648  2 nouveau,i915
serio_raw  16384  0
pcspkr 16384  0
snd_hwdep  16384  1 snd_hda_codec
mei_me 36864  0
snd_pcm   110592  4 
snd_hda_intel,snd_hda_codec,snd_hda_core,snd_hda_codec_hdmi
drm   360448  12 nouveau,i915,ttm,drm_kms_helper
snd_timer  32768  1 snd_pcm
mei   102400  1 mei_me
sg 32768  0
snd86016  20 
snd_hda_intel,snd_hwdep,snd_hda_codec,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec_realtek,snd_pcm
i2c_algo_bit   16384  2 nouveau,i915
soundcore  16384  1 snd
lpc_ich24576  0
shpchp 36864  0
mfd_core   16384  1 lpc_ich
wmi16384  3 asus_wmi,mxm_wmi,nouveau
battery20480  0
ac 16384  0
video  40960  3 asus_wmi,nouveau,i915
button 16384  2 nouveau,i915
coretemp   16384  0
parport_pc 28672  0
ppdev  20480  0
lp 20480  0
parport49152  3 lp,parport_pc,ppdev
ip_tables  24576  0
x_tables   36864  1 ip_tables
autofs440960  2
ext4  585728  5
crc16  16384  1 ext4
jbd2  106496  1 ext4
crc32c_generic 16384  0
fscrypto   

Re: linux wrongly treated as passing autopkgtests

[Ben Hutchings]

On Fri, 2018-06-29 at 23:21 +0100, Ben Hutchings wrote:
> Looking at
> .
> 
> I see the result:
> 
> selftestsSKIP Test requires machine-level isolation but 
> testbed does not provide that
> autopkgtest [00:39:46]:  summary
> selftestsSKIP Test requires machine-level isolation but 
> testbed does not provide that
> 
> It would be really good if you could implement machine isolation, but I
> understand that it may not be a high priority when so few packages need
> it.
> 
> However, this appears to be treated as a pass, for testing propagation
> purposes.  That's really not right - if a package's tests can't be run,
> I think this should be treated the same as a package missing tests.

dkg pointed me at bug #901847 etc., so there's no need to answer this.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


signature.asc
Description: This is a digitally signed message part

linux wrongly treated as passing autopkgtests

[Ben Hutchings]

Looking at
.

I see the result:

selftestsSKIP Test requires machine-level isolation but testbed 
does not provide that
autopkgtest [00:39:46]:  summary
selftestsSKIP Test requires machine-level isolation but testbed 
does not provide that

It would be really good if you could implement machine isolation, but I
understand that it may not be a high priority when so few packages need
it.

However, this appears to be treated as a pass, for testing propagation
purposes.  That's really not right - if a package's tests can't be run,
I think this should be treated the same as a package missing tests.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


signature.asc
Description: This is a digitally signed message part

Re: linux/unstable failing to build on mips

[Ben Hutchings]

On Fri, 2018-06-29 at 23:27 +0200, Aurelien Jarno wrote:
> On 2018-06-29 21:29, Ben Hutchings wrote:
[...]
> > Has there been any attempt to diagnose the hang?  If so, does it seem
> > to be due to memory exhaustion and extreme swapping, or a software bug,
> > or some other cause?  Why hasn't it happened when building earlier
> > versions?
> 
> Yes, attempted has been made, but it's something difficult to diagnose,
> the machine becoming unresponsive. make seems to leave many processes
> hanging, causing extreme swapping, which doesn't work well on the
> Octeons which swap over NFS. It seems to work fine on the Octeons which
> swap over NFS.

Swap over NFS is supposed to work since a few years ago, but I have my
doubts.  It is definitely a fragile feature.

[...]
> > If it's memory exhaustion, are linux and other large packages being
> > blacklisted for these build hosts?
> 
> In the meantime, I have blacklisted linux on the Octeons swapping over
> NFS. It should therefore build fine.

Thanks.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.



signature.asc
Description: This is a digitally signed message part

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Ben Hutchings]

On Fri, 2018-06-29 at 22:33 +0100, Ben Hutchings wrote:
> On Fri, 2018-06-29 at 22:31 +0200, Moritz Mühlenhoff wrote:
> > Niels Thykier wrote:
> > > If the issues and concerns from you or your team are not up to date,
> > > then please follow up to this email (keeping debian-release@l.d.o and
> > > debian-ports@l.d.o in CC to ensure both parties are notified).
> > 
> > Two issues that we discussed at the recent Security Team sprint wrt
> > problems affecting buster:
> > 
> > (1) Linux upstream security support for i386 seems at risk at this point.
> > E.g. KPTI for i386 still isn't merged in Linux master half a year later 
> > after
> > the public Meltdown disclosure in early January (and the development of KPTI
> > started months before that). Someone at SuSE actually developed patches
> > as an older SLES release using Linux 3.0 (!) still supports i386, but that
> > will also EOL at some point and if we don't have the manpower to
> > develop upstream fixes for future i386-specific flaws.
> > 
> > It's not a strict blocker, but we wanted to raise the discussion whether
> > it still makes sense to ship 32 bit kernels for buster, which means with
> > support until ~ 2022.
[...]

Also, if there is a question about the continued use of 32-bit x86
systems, it appears that the AMD Geode LX and VIA C7 processors are
still commercially available.

(I'm ignoring the Intel Quark since it can't run a standard i386 user-
space.)

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.



signature.asc
Description: This is a digitally signed message part

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Ben Hutchings]

On Fri, 2018-06-29 at 22:31 +0200, Moritz Mühlenhoff wrote:
> Niels Thykier wrote:
> > If the issues and concerns from you or your team are not up to date,
> > then please follow up to this email (keeping debian-release@l.d.o and
> > debian-ports@l.d.o in CC to ensure both parties are notified).
> 
> Two issues that we discussed at the recent Security Team sprint wrt
> problems affecting buster:
> 
> (1) Linux upstream security support for i386 seems at risk at this point.
> E.g. KPTI for i386 still isn't merged in Linux master half a year later after
> the public Meltdown disclosure in early January (and the development of KPTI
> started months before that). Someone at SuSE actually developed patches
> as an older SLES release using Linux 3.0 (!) still supports i386, but that
> will also EOL at some point and if we don't have the manpower to
> develop upstream fixes for future i386-specific flaws.
> 
> It's not a strict blocker, but we wanted to raise the discussion whether
> it still makes sense to ship 32 bit kernels for buster, which means with
> support until ~ 2022.
[...]

The lack of Meltdown mitigation on i386 is concerning, though I remain
somewhat hopeful that it will get fixes eventually.  A quick look
through kernel-sec finds maybe 3 other i386-specific issues in the last
5 years (CVE-2013-0190, CVE-2014-4508, CVE-2016-3672), and none of the
fixes were difficult to backport.

It's worth noting that Meltdown also never got mitigated for any of the
other affected architectures (at least ppc64el and s390x) in jessie,
despite being addressed upstream.  So I don't think it makes sense to
pick on i386 as being particularly vulnerable.

Also, I don't think it is currently tenable to have a release
architecture without a kernel.  We still don't have a way to
interactively install multiarch amd64/i386 systems.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


signature.asc
Description: This is a digitally signed message part

Re: linux/unstable failing to build on mips

[Aurelien Jarno]

On 2018-06-29 21:29, Ben Hutchings wrote:
> The latest upload of linux to unstable has failed to build on mips
> several times, with the failure mode being an apparent hang near the
> end of the build process.  (Only one of these failed builds is visible
> on buildd.debian.org now, but I think there were two previous
> attempts.)

That's correct.

> Has there been any attempt to diagnose the hang?  If so, does it seem
> to be due to memory exhaustion and extreme swapping, or a software bug,
> or some other cause?  Why hasn't it happened when building earlier
> versions?

Yes, attempted has been made, but it's something difficult to diagnose,
the machine becoming unresponsive. make seems to leave many processes
hanging, causing extreme swapping, which doesn't work well on the
Octeons which swap over NFS. It seems to work fine on the Octeons which
swap over NFS.

mips being one of the few architectures with a buggy version of make, I
wonder if it's related to #890430 or #890309. I guess it's time to
revert to the make version in testing, which would also greatly improve,
or rather restore, the build time.

> If it's memory exhaustion, are linux and other large packages being
> blacklisted for these build hosts?

In the meantime, I have blacklisted linux on the Octeons swapping over
NFS. It should therefore build fine.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Moritz Mühlenhoff]

Niels Thykier wrote:
> If the issues and concerns from you or your team are not up to date,
> then please follow up to this email (keeping debian-release@l.d.o and
> debian-ports@l.d.o in CC to ensure both parties are notified).

Two issues that we discussed at the recent Security Team sprint wrt
problems affecting buster:

(1) Linux upstream security support for i386 seems at risk at this point.
E.g. KPTI for i386 still isn't merged in Linux master half a year later after
the public Meltdown disclosure in early January (and the development of KPTI
started months before that). Someone at SuSE actually developed patches
as an older SLES release using Linux 3.0 (!) still supports i386, but that
will also EOL at some point and if we don't have the manpower to
develop upstream fixes for future i386-specific flaws.

It's not a strict blocker, but we wanted to raise the discussion whether
it still makes sense to ship 32 bit kernels for buster, which means with
support until ~ 2022.

(2) Not an architectual issue, but a cross-arch problem: Buster is
reaching a critical mass of applications written in Go and our tooling
for security updates is absolutely not in a position to deal with it's
approach to link everything statically:

dak on ftpmaster and security-master don't share tarballs, IOW the
first time an application is updated in foo-security it's needs an
upload including the orig tarball. That's somewhat manageable for
standard security updates, but if we'd need to recompile all reverse
deps with individual source uploads (which would be dozens to hundreds
of packages if it's e.g. in Golang itself), it ends up being total
madness.

To be able to support Go-based applications in buster-security we
need tooling which
- detects which packages need a rebuild if a given Go package has been
  fixed.
- handles the actual rebuilds and sharing tarballs between security-master
  and ftp-master is an automated manner

Cheers,
Moritz

linux/unstable failing to build on mips

[Ben Hutchings]

The latest upload of linux to unstable has failed to build on mips
several times, with the failure mode being an apparent hang near the
end of the build process.  (Only one of these failed builds is visible
on buildd.debian.org now, but I think there were two previous
attempts.)

Has there been any attempt to diagnose the hang?  If so, does it seem
to be due to memory exhaustion and extreme swapping, or a software bug,
or some other cause?  Why hasn't it happened when building earlier
versions?

If it's memory exhaustion, are linux and other large packages being
blacklisted for these build hosts?

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#902661: linux-image-4.16.0-2-amd64: kernel BUG at /build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:nvidia-graphics-drivers 390.67-1
Bug #902661 [src:linux] linux-image-4.16.0-2-amd64: kernel BUG at 
/build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!
Bug reassigned from package 'src:linux' to 'src:nvidia-graphics-drivers'.
No longer marked as found in versions linux/4.16.16-2.
Ignoring request to alter fixed versions of bug #902661 to the same values 
previously set
Bug #902661 [src:nvidia-graphics-drivers] linux-image-4.16.0-2-amd64: kernel 
BUG at /build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!
Marked as found in versions nvidia-graphics-drivers/390.67-1.

-- 
902661: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902661
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#902661: linux-image-4.16.0-2-amd64: kernel BUG at /build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!

[Ben Hutchings]

Control: reassign -1 src:nvidia-graphics-drivers 390.67-1

On Fri, 2018-06-29 at 11:02 +0200, Fabian wrote:
> Package: src:linux
> Version: 4.16.16-2
> Severity: important
> 
> Dear Maintainer,
> 
> starting X via 'startx' causes every screen to stay black, no more
> interaction with mouse or keyboards is possible. So I connected via ssh
> and tried to execute 'systemctl reboot'. Only the ssh connection was
> closed but the system stayed running without any interaction.
> After a reboot I looked again via ssh what dmesg prints out.
> It said "usercopy: Kernel memory exposure attempt detected from SLUB
> object 'nvidia_stack_cache' (offset: 11440, size 3)!", followed by the
> message mentioned in the subject.
> Therefore the system is not usable with X in this configuration.
> 
> nvidia-driver is in version 390.67-1
[...]

And the bug should have been reported against that.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.



signature.asc
Description: This is a digitally signed message part

Bug#902661: linux-image-4.16.0-2-amd64: kernel BUG at /build/linux-uwVqDp/linux-4.16.16/mm/usercopy.c:100!

[Fabian]

Package: src:linux
Version: 4.16.16-2
Severity: important

Dear Maintainer,

starting X via 'startx' causes every screen to stay black, no more
interaction with mouse or keyboards is possible. So I connected via ssh
and tried to execute 'systemctl reboot'. Only the ssh connection was
closed but the system stayed running without any interaction.
After a reboot I looked again via ssh what dmesg prints out.
It said "usercopy: Kernel memory exposure attempt detected from SLUB
object 'nvidia_stack_cache' (offset: 11440, size 3)!", followed by the
message mentioned in the subject.
Therefore the system is not usable with X in this configuration.

nvidia-driver is in version 390.67-1

-- Package-specific info:
** Version:
Linux version 4.16.0-2-amd64 (debian-kernel@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-23)) #1 SMP Debian 4.16.16-2 (2018-06-22)

** Command line:
BOOT_IMAGE=/vmlinuz-4.16.0-2-amd64 root=/dev/mapper/loki-root ro 
cgroup_enable=memory swapaccount=1 quiet

** Tainted: PDO (4225)
 * Proprietary module has been loaded.
 * Kernel has oopsed before.
 * Out-of-tree module has been loaded.

** Kernel log:
[  116.932901]  ? _nv028088rm+0x55/0x90 [nvidia]
[  116.933048]  ? _nv013695rm+0xee/0x100 [nvidia]
[  116.933195]  ? _nv015343rm+0x154/0x270 [nvidia]
[  116.933350]  ? _nv008317rm+0x134/0x1a0 [nvidia]
[  116.933505]  ? _nv008296rm+0x29c/0x2b0 [nvidia]
[  116.933661]  ? _nv001072rm+0xe/0x20 [nvidia]
[  116.933818]  ? _nv007324rm+0xd8/0x100 [nvidia]
[  116.933962]  ? _nv001171rm+0x627/0x830 [nvidia]
[  116.934106]  ? rm_ioctl+0x73/0x100 [nvidia]
[  116.934240]  ? nvidia_ioctl+0xb0/0x730 [nvidia]
[  116.934370]  ? nvidia_ioctl+0x57c/0x730 [nvidia]
[  116.934371]  ? kmem_cache_free+0x19c/0x1d0
[  116.934501]  ? nvidia_frontend_unlocked_ioctl+0x3e/0x50 [nvidia]
[  116.934502]  ? do_vfs_ioctl+0xa4/0x630
[  116.934504]  ? __fput+0x164/0x1e0
[  116.934505]  ? SyS_ioctl+0x74/0x80
[  116.934507]  ? do_syscall_64+0x6c/0x130
[  116.934508]  ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  116.934509] Code: 2e 00 00 44 8d 42 01 88 50 01 48 8b 05 4a 2e 00 00 8a 48 
02 48 8b 05 40 2e 00 00 41 0b c8 88 48 02 48 8b 05 33 2e 00 00 8a 48 02 <41> 84 
c8 74 0e 66 41 03 d0 b8 ff ff 00 00 66 3b d0 72 e3 f3 c3 
[  126.968483] INFO: NMI handler (nmi_cpu_backtrace_handler) took too long to 
run: 2.416 msecs
[  126.970325] general protection fault:  [#2] SMP NOPTI
[  126.970328] Modules linked in: ctr ccm ipt_MASQUERADE nf_nat_masquerade_ipv4 
nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype xt_conntrack nf_nat 
nf_conntrack br_netfilter bridge stp llc overlay aufs(O) ebtable_filter 
ebtables devlink ip6table_filter ip6_tables iptable_filter pci_stub vboxpci(O) 
vboxnetadp(O) vboxnetflt(O) vboxdrv(O) tun arc4 snd_hda_codec_hdmi nls_ascii 
rt2800usb nls_cp437 rt2x00usb vfat rt2800lib fat rt2x00lib eeepc_wmi asus_wmi 
sparse_keymap mac80211 snd_hda_codec_realtek video mxm_wmi wmi_bmof efi_pstore 
snd_hda_codec_generic cfg80211 edac_mce_amd kvm_amd ccp crc_ccitt rng_core 
evdev rfkill snd_hda_intel joydev kvm snd_hda_codec irqbypass serio_raw efivars 
fam15h_power sg snd_hda_core snd_hwdep snd_pcm snd_timer
[  126.970372]  snd wmi soundcore button shpchp sp5100_tco k10temp 
nvidia_drm(PO) drm_kms_helper drm nvidia_modeset(PO) nvidia(PO) ipmi_devintf 
ipmi_msghandler it87 hwmon_vid loop parport_pc ppdev lp parport efivarfs 
ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb algif_skcipher 
af_alg uas usb_storage dm_crypt dm_mod sr_mod cdrom raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor hid_holtek_mouse 
hid_generic usbhid hid sd_mod raid6_pq libcrc32c crc32c_generic raid1 raid0 
multipath linear md_mod ohci_pci crct10dif_pclmul crc32_pclmul crc32c_intel 
ghash_clmulni_intel pcbc ahci aesni_intel aes_x86_64 libahci crypto_simd 
glue_helper xhci_pci cryptd ohci_hcd ehci_pci libata xhci_hcd ehci_hcd 
i2c_piix4 usbcore e1000e usb_common scsi_mod
[  126.970449] CPU: 7 PID: 2270 Comm: Xorg Tainted: P  DO 
4.16.0-2-amd64 #1 Debian 4.16.16-2
[  126.970450] Hardware name: To be filled by O.E.M. To be filled by 
O.E.M./Crosshair V Formula, BIOS 1703 10/17/2012
[  126.970854] RIP: 0010:_nv007222rm+0x25/0x90 [nvidia]
[  126.970856] RSP: 0018:a199c4017d20 EFLAGS: 00010006
[  126.970858] RAX: 48e28944ff36 RBX: c14f82b8 RCX: a199c4017db0
[  126.970859] RDX: c089a515 RSI: 08de RDI: c14f82b8
[  126.970860] RBP: 8caf4d202ff8 R08:  R09: a199c4017dac
[  126.970861] R10:  R11: ff00 R12: 08de
[  126.970862] R13: 8caf4d855000 R14: 8caf87ec0f00 R15: 8caf85ef7000
[  126.970864] FS:  7f827a97f6c0() GS:8caf9edc() 
knlGS:
[  126.970866] CS:  0010 DS:  ES:  CR0: 80050033
[  126.970867] CR2: 7f4a27c12900 CR3: 0003af20a000 CR4: 000406e0

Bug#893393: linux-image-amd64: Kernel panic on active outgoing traffic through Huawei E173 modem in NDIS (CDC) mode

[Bjørn Mork]

This issue should be fixed by commit

 49c2c3f246e2 ("cdc_ncm: avoid padding beyond end of skb")

which has been backported to v4.17.3, v4.16.18 and v4.14.52.  Please
check again with one of those kernel versions (or newer).

I see now that the fix doesn't apply cleanly to v4.9 stable due to
unrelated context changes.  I'll go fix that and resubmit a backport for
v4.9, so we get the fix into "stretch" too.  Thanks for reminding me.



Bjørn

Bug#892105: i40e

[Jörg Kost]

Run into a similar issues with i40e. I found out that the i40e driver 
included in linux-image-4.9.0-6-amd64 drops ARP requests randomly if the 
interface is not configured into promiscuous mode (e.g. tcpdump 
running). Therefore if the switch / router expires or invalidates its 
arp cache, the system may not be reachable until the next ARP request 
will get randomly accepted & answered.


Workaround:
- Set up a static arp entry on the switch / router

Solution:
- Compile the current i40e driver from the Intel website, where the 
issue does not occur, in my case: 2.4.10


I did not test stretch-backports so far.