This bug was fixed in the package linux - 4.13.0-45.50
---------------
linux (4.13.0-45.50) artful; urgency=medium
* linux: 4.13.0-45.50 -proposed tracker (LP: #1774124)
* CVE-2018-3639 (x86)
- SAUCE: Set generic SSBD feature for Intel cpus
linux (4.13.0-44.49) artful; urgency=medium
* linux: 4.13.0-44.49 -proposed tracker (LP: #1772951)
* CVE-2018-3639 (x86)
- x86/cpu: Make alternative_msr_write work for 32-bit code
- x86/cpu/AMD: Fix erratum 1076 (CPB bit)
- x86/bugs: Fix the parameters alignment and missing void
- KVM: SVM: Move spec control call after restore of GS
- x86/speculation: Use synthetic bits for IBRS/IBPB/STIBP
- x86/cpufeatures: Disentangle MSR_SPEC_CTRL enumeration from IBRS
- x86/cpufeatures: Disentangle SSBD enumeration
- x86/cpufeatures: Add FEATURE_ZEN
- x86/speculation: Handle HT correctly on AMD
- x86/bugs, KVM: Extend speculation control for VIRT_SPEC_CTRL
- x86/speculation: Add virtualized speculative store bypass disable support
- x86/speculation: Rework speculative_store_bypass_update()
- x86/bugs: Unify x86_spec_ctrl_{set_guest,restore_host}
- x86/bugs: Expose x86_spec_ctrl_base directly
- x86/bugs: Remove x86_spec_ctrl_set()
- x86/bugs: Rework spec_ctrl base and mask logic
- x86/speculation, KVM: Implement support for VIRT_SPEC_CTRL/LS_CFG
- KVM: SVM: Implement VIRT_SPEC_CTRL support for SSBD
- x86/bugs: Rename SSBD_NO to SSB_NO
- KVM: VMX: Expose SSBD properly to guests.
* [Ubuntu 16.04] kernel: fix rwlock implementation (LP: #1761674)
- SAUCE: (no-up) s390: fix rwlock implementation
* CVE-2018-7492
- rds: Fix NULL pointer dereference in __rds_rdma_map
* CVE-2018-8781
- drm: udl: Properly check framebuffer mmap offsets
* fsnotify: Fix fsnotify_mark_connector race (LP: #1765564)
- fsnotify: Fix fsnotify_mark_connector race
* Kernel panic on boot (m1.small in cn-north-1) (LP: #1771679)
- x86/xen: Reset VCPU0 info pointer after shared_info remap
* Suspend to idle: Open lid didn't resume (LP: #1771542)
- ACPI / PM: Do not reconfigure GPEs for suspend-to-idle
* CVE-2018-1092
- ext4: fail ext4_iget for root directory if unallocated
* [SRU][Artful] using vfio-pci on a combination of cn8xxx and some PCI devices
results in a kernel panic. (LP: #1770254)
- PCI: Avoid bus reset if bridge itself is broken
- PCI: Mark Cavium CN8xxx to avoid bus reset
- PCI: Avoid slot reset if bridge itself is broken
* Battery drains when laptop is off (shutdown) (LP: #1745646)
- PCI / PM: Check device_may_wakeup() in pci_enable_wake()
* perf record crash: refcount_inc assertion failed (LP: #1769027)
- perf cgroup: Fix refcount usage
- perf xyarray: Fix wrong processing when closing evsel fd
* Dell Latitude 5490/5590 BIOS update 1.1.9 causes black screen at boot
(LP: #1764194)
- drm/i915/bios: filter out invalid DDC pins from VBT child devices
* Fix an issue that some PCI devices get incorrectly suspended (LP: #1764684)
- PCI / PM: Always check PME wakeup capability for runtime wakeup support
* [SRU][Bionic/Artful] fix false positives in W+X checking (LP: #1769696)
- init: fix false positives in W+X checking
* CVE-2018-1068
- netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets
* CVE-2018-8087
- mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl()
* Integrated Webcam Realtek Integrated_Webcam_HD (0bda:58f4) not working in
DELL XPS 13 9370 with firmware 1.50 (LP: #1763748)
- SAUCE: media: uvcvideo: Support realtek's UVC 1.5 device
* unregister_netdevice: waiting for eth0 to become free. Usage count = 5
(LP: #1746474)
- ipv4: convert dst_metrics.refcnt from atomic_t to refcount_t
- xfrm: reuse uncached_list to track xdsts
* Acer Swift sf314-52 power button not managed (LP: #1766054)
- SAUCE: platform/x86: acer-wmi: add another KEY_POWER keycode
* set PINCFG_HEADSET_MIC to parse_flags for Dell precision 3630 (LP: #1766398)
- ALSA: hda/realtek - set PINCFG_HEADSET_MIC to parse_flags
* Change the location for one of two front mics on a lenovo thinkcentre
machine (LP: #1766477)
- ALSA: hda/realtek - adjust the location of one mic
-- Stefan Bader <stefan.ba...@canonical.com> Mon, 28 May 2018 16:10:36
+0200
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1765564
Title:
fsnotify: Fix fsnotify_mark_connector race
Status in Linux:
Incomplete
Status in linux package in Ubuntu:
Invalid
Status in linux-azure package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
Invalid
Status in linux-azure source package in Xenial:
Fix Released
Status in linux source package in Artful:
Fix Released
Status in linux-azure source package in Artful:
Invalid
Status in linux source package in Bionic:
Fix Released
Status in linux-azure source package in Bionic:
Fix Released
Bug description:
On Azure we have had sporadic cases of soft lockups in fsnotify that
may very well be mitigated by the following fix. The LKML thread is
"kernel panics with 4.14.X".
This should be applied to 4.13 and 4.15 versions of the linux-azure
kernel, and possibly the 4.15 generic kernel in bionic as well.
-----
fsnotify() acquires a reference to a fsnotify_mark_connector through
the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it
appears that no precautions are taken in fsnotify_put_mark() to
ensure that fsnotify() drops its reference to this
fsnotify_mark_connector before assigning a value to its 'destroy_next'
field. This can result in fsnotify_put_mark() assigning a value
to a connector's 'destroy_next' field right before fsnotify() tries to
traverse the linked list referenced by the connector's 'list' field.
Since these two fields are members of the same union, this behavior
results in a kernel panic.
This issue is resolved by moving the connector's 'destroy_next' field
into the object pointer union. This should work since the object pointer
access is protected by both a spinlock and the value of the 'flags'
field, and the 'flags' field is cleared while holding the spinlock in
fsnotify_put_mark() before 'destroy_next' is updated. It shouldn't be
possible for another thread to accidentally read from the object pointer
after the 'destroy_next' field is updated.
The offending behavior here is extremely unlikely; since
fsnotify_put_mark() removes references to a connector (specifically,
it ensures that the connector is unreachable from the inode it was
formerly attached to) before updating its 'destroy_next' field, a
sizeable chunk of code in fsnotify_put_mark() has to execute in the
short window between when fsnotify() acquires the connector reference
and saves the value of its 'list' field. On the HEAD kernel, I've only
been able to reproduce this by inserting a udelay(1) in fsnotify().
However, I've been able to reproduce this issue without inserting a
udelay(1) anywhere on older unmodified release kernels, so I believe
it's worth fixing at HEAD.
References: https://bugzilla.kernel.org/show_bug.cgi?id=199437
Fixes: 08991e83b7286635167bab40927665a90fb00d81
CC: sta...@vger.kernel.org
Signed-off-by: Robert Kolchmeyer <rkolchme...@google.com>
Signed-off-by: Jan Kara <j...@suse.cz>
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1765564/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
