This bug was fixed in the package linux - 3.13.0-162.212
---------------
linux (3.13.0-162.212) trusty; urgency=medium
* linux: 3.13.0-162.212 -proposed tracker (LP: #1799399)
* packet socket panic in Trusty 3.13.0-157 and later (LP: #1800254)
- SAUCE: (no-up) net/packet: fix erroneous dev_add_pack usage in fanout
* Cleanup Meltdown/Spectre implementation (LP: #1779848)
- x86/Documentation: Add PTI description
- Revert "x86/cpu/AMD: Make the LFENCE instruction serialized"
- x86/cpu/AMD: Make LFENCE a serializing instruction
- x86/cpu/AMD: Use LFENCE_RDTSC in preference to MFENCE_RDTSC
- x86/pti: Document fix wrong index
- x86/nospec: Fix header guards names
- x86/bugs: Drop one "mitigation" from dmesg
- x86/spectre: Check CONFIG_RETPOLINE in command line parser
- x86/spectre: Simplify spectre_v2 command line parsing
- x86/spectre: Fix an error message
- SAUCE: x86/cpufeatures: Reorder spectre-related feature bits
- x86/cpufeatures: Add AMD feature bits for Speculation Control
- SAUCE: x86/msr: Fix formatting of msr-index.h
- SAUCE: x86/msr: Rename MSR spec control feature bits
- x86/pti: Mark constant arrays as __initconst
- x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier)
support
- x86/cpufeatures: Clean up Spectre v2 related CPUID flags
- x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel
- SAUCE: x86/speculation: Use synthetic bits for IBRS/IBPB/STIBP
- SAUCE: x86/cpufeatures: Disentangle MSR_SPEC_CTRL enumeration from IBRS
- x86/speculation: Use IBRS if available before calling into firmware
- x86/speculation: Move firmware_restrict_branch_speculation_*() from C to
CPP
- SAUCE: x86/bugs: Fix re-use of SPEC_CTRL MSR boot value
- SAUCE: Move SSBD feature detection to common code
- SAUCE: x86/speculation: Move vendor specific IBRS/IBPB control code
- SAUCE: x86/speculation: Query individual feature flags when reloading
microcode
- xen: Add xen_arch_suspend()
- x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend
- SAUCE: x86/pti: Evaluate X86_BUG_CPU_MELTDOWN when pti=auto
- SAUCE: x86/speculation: Make use of indirect_branch_prediction_barrier()
- SAUCE: x86/speculation: Cleanup IBPB runtime control handling
- SAUCE: x86/speculation: Cleanup IBRS runtime control handling
* CVE-2016-9588
- kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)
* CVE-2017-16649
- net: cdc_ether: fix divide by 0 on bad descriptors
* CVE-2018-9363
- Bluetooth: hidp: buffer overflow in hidp_process_report
* CVE-2017-13168
- scsi: sg: mitigate read/write abuse
* xattr length returned by vfs_getxattr() is not correct in Trusty kernel
(LP: #1798013)
- getxattr: use correct xattr length
* CVE-2018-16658
- cdrom: Fix info leak/OOB read in cdrom_ioctl_drive_status
-- Stefan Bader <stefan.ba...@canonical.com> Mon, 29 Oct 2018 11:31:15
+0100
** Changed in: linux (Ubuntu Trusty)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-9588
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-13168
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-16649
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-16658
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-9363
--
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/1800254
Title:
packet socket panic in Trusty 3.13.0-157 and later
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Trusty:
Fix Released
Bug description:
SRU Justification:
Due to changes added as part of c108ac876c02 ("packet: hold bind lock when
rebinding to fanout hook"), it is possible for fanout_add to add a
packet_type handler via dev_add_pack and then kfree the memory backing the
packet_type. This corrupts the ptype_all list, causing the system to
panic when network packet processing next traverses ptype_all. The
erroneous path is taken when a PACKET_FANOUT setsockopt is performed on a
packet socket that is bound to an interface that is administratively down.
This is not due to any flaw of c108ac876c02, but rather than the packet
socket code base differs subtly in 3.13 as compared to 4.4.
This affects only the Trusty 3.13 kernel series, starting with
3.13.0-157.
Fix:
The remedy for this is to backport additional changes in the management of
the dev_add_pack calls from 4.4. This moves the dev_add_pack and
dev_remove_pack calls from fanout_add and _release into __fanout_link and
_unlink.
Testcase:
The issue can be reproduced reliably by (a) creating an AF_PACKET socket,
binding it to an interface that is administratively down, and then (c)
attempting to set the PACKET_FANOUT sockopt. The setsockopt call will
fail, but will corrupt ptype_all in the kernel. Subsequent network traffic
will induce a panic when evaulating the corrupted ptype_all entry. A
test program is attached.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1800254/+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
