group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1765564@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package linux-azure - 4.13.0-1018.21

---------------
linux-azure (4.13.0-1018.21) xenial; urgency=medium

  [ Ubuntu: 4.13.0-43.48 ]

  * CVE-2018-3639 (powerpc)
    - SAUCE: rfi-flush: update H_CPU_* macro names to upstream
    - SAUCE: rfi-flush: update plpar_get_cpu_characteristics() signature to
      upstream
    - SAUCE: update pseries_setup_rfi_flush() capitalization to upstream
    - powerpc/pseries: Support firmware disable of RFI flush
    - powerpc/powernv: Support firmware disable of RFI flush
    - powerpc/64s: Allow control of RFI flush via debugfs
    - powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
    - powerpc/rfi-flush: Always enable fallback flush on pseries
    - powerpc/rfi-flush: Differentiate enabled and patched flush types
    - powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
    - powerpc: Add security feature flags for Spectre/Meltdown
    - powerpc/powernv: Set or clear security feature flags
    - powerpc/pseries: Set or clear security feature flags
    - powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
    - powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
    - powerpc/pseries: Fix clearing of security feature flags
    - powerpc: Move default security feature flags
    - powerpc/pseries: Restore default security feature flags on setup
    - powerpc/64s: Add support for a store forwarding barrier at kernel entry/exit
  * CVE-2018-3639 (x86)
    - SAUCE: Add X86_FEATURE_ARCH_CAPABILITIES
    - SAUCE: x86: Add alternative_msr_write
    - x86/nospec: Simplify alternative_msr_write()
    - x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
    - x86/bugs: Concentrate bug detection into a separate function
    - x86/bugs: Concentrate bug reporting into a separate function
    - x86/msr: Add definitions for new speculation control MSRs
    - x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
    - x86/bugs, KVM: Support the combination of guest and host IBRS
    - x86/bugs: Expose /sys/../spec_store_bypass
    - x86/cpufeatures: Add X86_FEATURE_RDS
    - x86/bugs: Provide boot parameters for the spec_store_bypass_disable
      mitigation
    - x86/bugs/intel: Set proper CPU features and setup RDS
    - x86/bugs: Whitelist allowed SPEC_CTRL MSR values
    - x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
    - x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
    - x86/speculation: Create spec-ctrl.h to avoid include hell
    - prctl: Add speculation control prctls
    - x86/process: Allow runtime control of Speculative Store Bypass
    - x86/speculation: Add prctl for Speculative Store Bypass mitigation
    - nospec: Allow getting/setting on non-current task
    - proc: Provide details on speculation flaw mitigations
    - seccomp: Enable speculation flaw mitigations
    - SAUCE: x86/bugs: Honour SPEC_CTRL default
    - x86/bugs: Make boot modes __ro_after_init
    - prctl: Add force disable speculation
    - seccomp: Use PR_SPEC_FORCE_DISABLE
    - seccomp: Add filter flag to opt-out of SSB mitigation
    - seccomp: Move speculation migitation control to arch code
    - x86/speculation: Make "seccomp" the default mode for Speculative Store
      Bypass
    - x86/bugs: Rename _RDS to _SSBD
    - proc: Use underscores for SSBD in 'status'
    - Documentation/spec_ctrl: Do some minor cleanups
    - x86/bugs: Fix __ssb_select_mitigation() return type
    - x86/bugs: Make cpu_show_common() static
  * LSM Stacking prctl values should be redefined as to not collide with
    upstream prctls (LP: #1769263) // CVE-2018-3639
    - SAUCE: LSM stacking: adjust prctl values

  [ Ubuntu: 4.13.0-42.47 ]

  * linux: 4.13.0-42.47 -proposed tracker (LP: #1769993)
  * arm64: fix CONFIG_DEBUG_WX address reporting (LP: #1765850)
    - arm64: fix CONFIG_DEBUG_WX address reporting
  * HiSilicon HNS NIC names are truncated in /proc/interrupts (LP: #1765977)
    - net: hns: Avoid action name truncation
  * CVE-2017-18208
    - mm/madvise.c: fix madvise() infinite loop under special circumstances
  * CVE-2018-8822
    - staging: ncpfs: memory corruption in ncp_read_kernel()
  * CVE-2017-18203
    - dm: fix race between dm_get_from_kobject() and __dm_destroy()
  * CVE-2017-17449
    - netlink: Add netns check on taps
  * CVE-2017-17975
    - media: usbtv: prevent double free in error case
  * [8086:3e92] display becomes blank after S3 (LP: #1763271)
    - drm/i915/edp: Allow alternate fixed mode for eDP if available.
    - drm/i915/dp: rename intel_dp_is_edp to intel_dp_is_port_edp
    - drm/i915/dp: make is_edp non-static and rename to intel_dp_is_edp
    - drm/i915/edp: Do not do link training fallback or prune modes on EDP
  * sky2 gigabit ethernet driver sometimes stops working after lid-open resume
    from sleep (88E8055) (LP: #1758507)
    - sky2: Increase D3 delay to sky2 stops working after suspend
  * perf vendor events arm64: Enable JSON events for ThunderX2 B0 (LP: #1760712)
    - perf vendor events arm64: Enable JSON events for ThunderX2 B0
  * No network with e1000e driver on 4.13.0-38-generic (LP: #1762693)
    - e1000e: Fix e1000_check_for_copper_link_ich8lan return value.
  * /dev/ipmi enumeration flaky on Cavium Sabre nodes (LP: #1762812)
    - i2c: xlp9xx: return ENXIO on slave address NACK
    - i2c: xlp9xx: Handle transactions with I2C_M_RECV_LEN properly
    - i2c: xlp9xx: Check for Bus state before every transfer
    - i2c: xlp9xx: Handle NACK on DATA properly
  * "ip a" command on a guest VM shows UNKNOWN status (LP: #1761534)
    - virtio-net: Fix operstate for virtio when no VIRTIO_NET_F_STATUS
  * fix regression in mm/hotplug, allows NVIDIA driver to work (LP: #1761104)
    - SAUCE: Fix revert "mm, memory_hotplug: do not associate hotadded memory to
      zones until online"
  * ibrs/ibpb fixes result in excessive kernel logging  (LP: #1755627)
    - SAUCE: remove ibrs_dump sysctl interface

linux-azure (4.13.0-1017.20) xenial; urgency=medium

  * linux-azure: 4.13.0-1017.20 -proposed tracker (LP: #1769997)

  * fsnotify: Fix fsnotify_mark_connector race (LP: #1765564)
    - fsnotify: Fix fsnotify_mark_connector race

 -- Stefan Bader <stefan.bader@xxxxxxxxxxxxx>  Thu, 17 May 2018 15:23:08
+0200

** Changed in: linux-azure (Ubuntu Xenial)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1765564

Title:
  fsnotify: Fix fsnotify_mark_connector race

Status in Linux:
  New
Status in linux-azure package in Ubuntu:
  In Progress
Status in linux-azure source package in Xenial:
  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: stable@xxxxxxxxxxxxxxx
  Signed-off-by: Robert Kolchmeyer <rkolchmeyer@xxxxxxxxxx>
  Signed-off-by: Jan Kara <jack@xxxxxxx>

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1765564/+subscriptions