[Group.of.nepali.translators] [Bug 1765241] Re: virtio_scsi race can corrupt memory, panic kernel

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.4.0-127.153

---
linux (4.4.0-127.153) xenial; urgency=medium

  * CVE-2018-3639 (powerpc)
- powerpc/pseries: Support firmware disable of RFI flush
- powerpc/powernv: Support firmware disable of RFI flush
- powerpc/rfi-flush: Move the logic to avoid a redo into the debugfs code
- powerpc/rfi-flush: Make it possible to call setup_rfi_flush() again
- powerpc/rfi-flush: Always enable fallback flush on pseries
- powerpc/rfi-flush: Differentiate enabled and patched flush types
- powerpc/rfi-flush: Call setup_rfi_flush() after LPM migration
- powerpc/pseries: Add new H_GET_CPU_CHARACTERISTICS flags
- powerpc: Add security feature flags for Spectre/Meltdown
- powerpc/pseries: Set or clear security feature flags
- powerpc/powernv: Set or clear security feature flags
- powerpc/64s: Move cpu_show_meltdown()
- powerpc/64s: Enhance the information in cpu_show_meltdown()
- powerpc/powernv: Use the security flags in pnv_setup_rfi_flush()
- powerpc/pseries: Use the security flags in pseries_setup_rfi_flush()
- powerpc/64s: Wire up cpu_show_spectre_v1()
- powerpc/64s: Wire up cpu_show_spectre_v2()
- powerpc/pseries: Fix clearing of security feature flags
- powerpc: Move default security feature flags
- powerpc/pseries: Restore default security feature flags on setup
- SAUCE: powerpc/64s: Add support for a store forwarding barrier at kernel
  entry/exit

  * CVE-2018-3639 (x86)
- SAUCE: Clean up IBPB and IBRS control functions and macros
- SAUCE: Fix up IBPB and IBRS kernel parameters documentation
- SAUCE: Remove #define X86_FEATURE_PTI
- x86/cpufeature: Move some of the scattered feature bits to x86_capability
- x86/cpufeature: Cleanup get_cpu_cap()
- x86/cpu: Probe CPUID leaf 6 even when cpuid_level == 6
- x86/cpufeatures: Add CPUID_7_EDX CPUID leaf
- x86/cpufeatures: Add Intel feature bits for Speculation Control
- SAUCE: x86/kvm: Expose SPEC_CTRL from the leaf
- x86/cpufeatures: Add AMD feature bits for Speculation Control
- x86/msr: Add definitions for new speculation control MSRs
- SAUCE: x86/msr: Rename MSR spec control feature bits
- x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
- x86/cpufeature: Blacklist SPEC_CTRL/PRED_CMD on early Spectre v2 
microcodes
- x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) 
support
- x86/speculation: Add  dependency
- x86/cpufeatures: Clean up Spectre v2 related CPUID flags
- x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel
- SAUCE: x86/speculation: Move vendor specific IBRS/IBPB control code
- SAUCE: x86: Add alternative_msr_write
- SAUCE: x86/nospec: Simplify alternative_msr_write()
- SAUCE: x86/bugs: Concentrate bug detection into a separate function
- SAUCE: x86/bugs: Concentrate bug reporting into a separate function
- arch: Introduce post-init read-only memory
- SAUCE: x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- SAUCE: x86/bugs, KVM: Support the combination of guest and host IBRS
- SAUCE: x86/bugs: Expose /sys/../spec_store_bypass
- SAUCE: x86/cpufeatures: Add X86_FEATURE_RDS
- SAUCE: x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- SAUCE: x86/bugs/intel: Set proper CPU features and setup RDS
- SAUCE: x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- SAUCE: x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if
  requested
- SAUCE: x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- SAUCE: x86/speculation: Create spec-ctrl.h to avoid include hell
- SAUCE: prctl: Add speculation control prctls
- x86/process: Optimize TIF checks in __switch_to_xtra()
- SAUCE: x86/process: Allow runtime control of Speculative Store Bypass
- SAUCE: x86/speculation: Add prctl for Speculative Store Bypass mitigation
- SAUCE: nospec: Allow getting/setting on non-current task
- SAUCE: proc: Provide details on speculation flaw mitigations
- SAUCE: seccomp: Enable speculation flaw mitigations
- SAUCE: x86/bugs: Honour SPEC_CTRL default
- SAUCE: x86/bugs: Make boot modes __ro_after_init
- SAUCE: prctl: Add force disable speculation
- SAUCE: seccomp: Use PR_SPEC_FORCE_DISABLE
- selftest/seccomp: Fix the flag name SECCOMP_FILTER_FLAG_TSYNC
- SAUCE: seccomp: Add filter flag to opt-out of SSB mitigation
- SAUCE: seccomp: Move speculation migitation control to arch code
- SAUCE: x86/speculation: Make "seccomp" the default mode for Speculative
  Store Bypass
- SAUCE: x86/bugs: Rename _RDS to _SSBD
- SAUCE: proc: Use underscores for SSBD in 'status'
- SAUCE: Documentation/spec_ctrl: Do some minor cleanups
- SAUCE: x86/bugs: Fix __ssb_select_mitigation() return type
- SAUCE: x86/bugs: Make cpu_show_common() static

[Group.of.nepali.translators] [Bug 1765241] Re: virtio_scsi race can corrupt memory, panic kernel

[Stefan Bader]

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Xenial)
   Status: New => In Progress

-- 
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/1765241

Title:
  virtio_scsi race can corrupt memory, panic kernel

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  In Progress

Bug description:
  There's a race in the virtio_scsi driver (for all kernels)

  That race is inadvertently avoided on most kernels due to a
  synchronize_rcu call coincidentally placed in one of the racing code paths

  By happenstance, the set of patches backported to the Ubuntu
  4.4 kernel ended up without a synchronize_rcu in the relevant place. The
  issue first manifests with 

  
  commit be2a20802abbde04ae09846406d7b670731d97d2
  Author: Jan Kara 
  Date:   Wed Feb 8 08:05:56 2017 +0100

  block: Move bdi_unregister() to del_gendisk()
  
  BugLink: http://bugs.launchpad.net/bugs/1659111

  The race can cause a kernel panic due to corruption of a freelist
  pointer in a slab cache.  The panics occur in arbitrary places as
  the failure occurs at an allocation after the corruption of the
  pointer.  However, the most common failure observed has been within
  virtio_scsi itself during probe processing, e.g.:

  [3.111628]  [] kfree_const+0x22/0x30
  [3.112340]  [] kobject_release+0x94/0x190
  [3.113126]  [] kobject_put+0x27/0x50
  [3.113838]  [] put_device+0x17/0x20
  [3.114568]  [] __scsi_remove_device+0x92/0xe0
  [3.115401]  [] scsi_probe_and_add_lun+0x95b/0xe80
  [3.116287]  [] ? kmem_cache_alloc_trace+0x183/0x1f0
  [3.117227]  [] ? __pm_runtime_resume+0x5b/0x80
  [3.118048]  [] __scsi_scan_target+0x10a/0x690
  [3.118879]  [] scsi_scan_channel+0x7e/0xa0
  [3.119653]  [] scsi_scan_host_selected+0xf3/0x160
  [3.120506]  [] do_scsi_scan_host+0x8d/0x90
  [3.121295]  [] do_scan_async+0x1c/0x190
  [3.122048]  [] async_run_entry_fn+0x48/0x150
  [3.122846]  [] process_one_work+0x165/0x480
  [3.123732]  [] worker_thread+0x4b/0x4d0
  [3.124508]  [] ? process_one_work+0x480/0x480

  
  Details on the race:

  CPU A:

  virtscsi_probe
  [...]
  __scsi_scan_target
  scsi_probe_and_add_lun  [on return calls  __scsi_remove_device, below]
  scsi_probe_lun  
  [...]
  blk_execute_rq

  blk_execute_rq waits for the completion event, and then on wakeup
  returns up to scsi_probe_and_all_lun, which calls __scsi_remove_device.
  In order for the race to occur, the wakeup must occur on a CPU other than
  CPU B.

  After being woken up by the completion of the request, the call
  returns up the stack to scsi_probe_and_add_lun, which calls
  __scsi_remove_device:

  __scsi_remove_device
  blk_cleanup_queue
  [ no longer calls bdi_unregister ]
  scsi_target_reap(scsi_target(sdev))
  scsi_target_reap_ref_put
  kref_put
  kref_sub
  scsi_target_reap_ref_release
  scsi_target_destroy
  ->target_destroy() = virtscsi_target_destroy
  kfree(tgt)  <=== FREE TGT

  Note that the removal of the call to bdi_unregister in commit

xenial be2a20802abbde block: Move bdi_unregister() to del_gendisk()

  and annotated above is the change that gates whether the issue
  manifests or not.  The other code change from be2a20802abbde has no effect
  on the race.

  CPU B:

  vring_interrupt
  virtscsi_complete_cmd
  scsi_mq_done (via ->scsi_done())
  scsi_mq_done
  blk_mq_complete_request
  __blk_mq_complete_request
  [...]
  blk_end_sync_rq
  complete
  [ wake up the task from CPU A ]

  After waking the CPU A task, execution returns up the stack, and
  then calls atomic_dec(>reqs) in virtscsi_complete_cmd immediately
  after returning from the call to ->scsi_done.

  If the activity on CPU A after it is woken up (starting at
  __scsi_remove_device) finishes before CPU B can call atomic_dec() in
  virtscsi_complete_cmd, then the atomic_dec() will modify a free list
  pointer in the freed slab object that contained tgt.  This causes the
  system to panic on a subsequent allocation from the per-cpu slab cache.

  The call path on CPU B is significantly shorter than that on CPU A
  after wakeup, so it is likely that an external event delays CPU B.  This
  could be either an interrupt within the VM or scheduling delays for the
  virtual cpu process on the hypervisor.  Whatever the delay is, it is not
  the root cause but merely the triggering event.

  The virtscsi race window described above exists in all kernels
  that have been checked (4.4 upstream LTS, Ubuntu 4.13 and 4.15, and
  current mainline as of this writing).