This bug was fixed in the package linux - 4.13.0-11.12
---------------
linux (4.13.0-11.12) artful; urgency=low
* linux: 4.13.0-11.12 -proposed tracker (LP: #1716699)
* kernel panic -not syncing: Fatal exception: panic_on_oops (LP: #1708399)
- s390/mm: fix local TLB flushing vs. detach of an mm address space
- s390/mm: fix race on mm->context.flush_mm
* CVE-2017-1000251
- Bluetooth: Properly check L2CAP config option output buffer length
-- Seth Forshee <[email protected]> Tue, 12 Sep 2017 10:18:38
-0500
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-1000251
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1715578
Title:
[Patch] network-i40e:NVM bug fixes (cherrypick from 4.14)
Status in intel:
New
Status in linux package in Ubuntu:
Fix Released
Bug description:
Description:
Theses two commits need to be cherrypicked from upstream to 4.12/4.13 and
integrated into 17.10
Target Kernel: 4.14
Target Release: 17.10
Action: Cherrypick
Here are the two commit id's:
commit 3c8f3e96af3a6799841761923d000566645f0942
Author: Jacob Keller <[email protected]>
Date: Fri Sep 1 13:43:08 2017 -0700
i40e: point wb_desc at the nvm_wb_desc during i40e_read_nvm_aq
When introducing the functions to read the NVM through the AdminQ,
we
did not correctly mark the wb_desc.
Fixes: 7073f46e443e ("i40e: Add AQ commands for NVM Update for
X722", 2015-06-05)
Signed-off-by: Jacob Keller <[email protected]>
Tested-by: Andrew Bowers <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
commit 09f79fd49d94cda5837e9bfd0cb222232b3b6d9f
Author: Anjali Singhai Jain <[email protected]>
Date: Fri Sep 1 13:42:49 2017 -0700
i40e: avoid NVM acquire deadlock during NVM update
X722 devices use the AdminQ to access the NVM, and this requires
taking
the AdminQ lock. Because of this, we lock the AdminQ during
i40e_read_nvm(), which is also called in places where the lock is
already held, such as the firmware update path which wants to lock
once
and then unlock when finished after performing several tasks.
Although this should have only affected X722 devices, commit
96a39aed25e6 ("i40e: Acquire NVM lock before reads on all devices",
2016-12-02) added locking for all NVM reads, regardless of device
family.
This resulted in us accidentally causing NVM acquire timeouts on
all
devices, causing failed firmware updates which left the eeprom in
a corrupt state.
Create unsafe non-locked variants of i40e_read_nvm_word and
i40e_read_nvm_buffer, __i40e_read_nvm_word and
__i40e_read_nvm_buffer
respectively. These variants will not take the NVM lock and are
expected
to only be called in places where the NVM lock is already held if
needed.
Since the only caller of i40e_read_nvm_buffer() was in such a path,
remove it entirely in favor of the unsafe version. If necessary we
can
always add it back in the future.
Additionally, we now need to hold the NVM lock in
i40e_validate_checksum
because the call to i40e_calc_nvm_checksum now assumes that the NVM
lock
is held. We can further move the call to read
I40E_SR_SW_CHECKSUM_WORD
up a bit so that we do not need to acquire the NVM lock twice.
This should resolve firmware updates and also fix potential raise
that
could have caused the driver to report an invalid NVM checksum upon
driver load.
Reported-by: Stefan Assmann <[email protected]>
Fixes: 96a39aed25e6 ("i40e: Acquire NVM lock before reads on all
devices", 2016-12-02)
Signed-off-by: Anjali Singhai Jain <[email protected]>
Signed-off-by: Jacob Keller <[email protected]>
Tested-by: Andrew Bowers <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
To manage notifications about this bug go to:
https://bugs.launchpad.net/intel/+bug/1715578/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
