This bug was fixed in the package linux - 3.13.0-153.203
---------------
linux (3.13.0-153.203) trusty; urgency=medium
* linux: 3.13.0-153.203 -proposed tracker (LP: #1776819)
* CVE-2018-3665 (x86)
- x86/fpu: Print out whether we are doing lazy/eager FPU context switches
- x86/fpu: Default eagerfpu=on on all CPUs
- x86/fpu: Fix math emulation in eager fpu mode
linux (3.13.0-152.202) trusty; urgency=medium
* linux: 3.13.0-152.202 -proposed tracker (LP: #1776350)
* CVE-2017-15265
- ALSA: seq: Fix use-after-free at creating a port
* register on binfmt_misc may overflow and crash the system (LP: #1775856)
- fs/binfmt_misc.c: do not allow offset overflow
* CVE-2018-1130
- dccp: check sk for closed state in dccp_sendmsg()
- ipv6: dccp: add missing bind_conflict to dccp_ipv6_mapped
* add_key04 in LTP syscall test cause kernel oops (NULL pointer dereference)
with T kernel (LP: #1775316) // CVE-2017-12193
- assoc_array: Fix a buggy node-splitting case
* CVE-2017-12154
- kvm: nVMX: Don't allow L2 to access the hardware CR8
* CVE-2018-7757
- scsi: libsas: fix memory leak in sas_smp_get_phy_events()
* CVE-2018-6927
- futex: Prevent overflow by strengthen input validation
* FS-Cache: Assertion failed: FS-Cache: 6 == 5 is false (LP: #1774336)
- SAUCE: CacheFiles: fix a read_waiter/read_copier race
* CVE-2018-5803
- sctp: verify size of a new chunk in _sctp_make_chunk()
* WARNING: CPU: 28 PID: 34085 at /build/linux-
90Gc2C/linux-3.13.0/net/core/dev.c:1433 dev_disable_lro+0x87/0x90()
(LP: #1771480)
- net/core: generic support for disabling netdev features down stack
- SAUCE: Backport helper function netdev_upper_get_next_dev_rcu
* CVE-2018-7755
- SAUCE: floppy: Do not copy a kernel pointer to user memory in FDGETPRM
ioctl
* CVE-2018-5750
- ACPI: sbshc: remove raw pointer from printk() message
-- Stefan Bader <stefan.ba...@canonical.com> Thu, 14 Jun 2018 07:00:42
+0200
** Changed in: linux (Ubuntu Bionic)
Status: Fix Committed => 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/1774336
Title:
FS-Cache: Assertion failed: FS-Cache: 6 == 5 is false
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Trusty:
Fix Released
Status in linux source package in Xenial:
Fix Released
Status in linux source package in Artful:
Fix Released
Status in linux source package in Bionic:
Fix Released
Bug description:
== SRU Justification ==
[Impact]
Oops during heavy NFS + FSCache use:
[81738.886634] FS-Cache:
[81738.888281] FS-Cache: Assertion failed
[81738.889461] FS-Cache: 6 == 5 is false
[81738.890625] ------------[ cut here ]------------
[81738.891706] kernel BUG at
/build/linux-hVVhWi/linux-4.4.0/fs/fscache/operation.c:494!
6 == 5 represents an operation being DEAD when it was not expected to
be.
[Cause]
There is a race in fscache and cachefiles.
One thread is in cachefiles_read_waiter:
1) object->work_lock is taken.
2) the operation is added to the to_do list.
3) the work lock is dropped.
4) fscache_enqueue_retrieval is called, which takes a reference.
Another thread is in cachefiles_read_copier:
1) object->work_lock is taken
2) an item is popped off the to_do list.
3) object->work_lock is dropped.
4) some processing is done on the item, and fscache_put_retrieval() is
called, dropping a reference.
Now if the this process in cachefiles_read_copier takes place
*between* steps 3 and 4 in cachefiles_read_waiter, a reference will be
dropped before it is taken, which leads to the objects reference count
hitting zero, which leads to lifecycle events for the object happening
too soon, leading to the assertion failure later on.
(This is simplified and clarified from the original upstream analysis
for this patch at https://www.redhat.com/archives/linux-
cachefs/2018-February/msg00001.html and from a similar patch with a
different approach to fixing the bug at
https://www.redhat.com/archives/linux-cachefs/2017-June/msg00002.html)
[Fix]
Move fscache_enqueue_retrieval under the lock in cachefiles_read_waiter. This
means that the object cannot be popped off the to_do list until it is in a
fully consistent state with the reference taken.
[Testcase]
A user has run ~100 hours of NFS stress tests and not seen this bug recur.
[Regression Potential]
- Limited to fscache/cachefiles.
- The change makes things more conservative (doing more under lock) so
that's reassuring.
- There may be performance impacts but none have been observed so far.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774336/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
