Bug 979215 (CVE-2016-3070) - VUL-0: CVE-2016-3070: kernel: Null pointer dereference in trace_writeback_dirty_page()
Summary: VUL-0: CVE-2016-3070: kernel: Null pointer dereference in trace_writeback_dir...
Status: RESOLVED FIXED
Alias: CVE-2016-3070
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P4 - Low : Normal
Target Milestone: ---
Assignee: Vlastimil Babka
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/168780/
Whiteboard: CVSSv2:SUSE:CVE-2016-3070:4.7:(AV:L/A...
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-10 08:23 UTC by Sebastian Krahmer
Modified: 2020-06-18 07:17 UTC (History)
6 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 2 Michal Hocko 2016-05-16 06:06:07 UTC
Vlastimil, could you have a look?
Comment 3 Marcus Meissner 2017-03-01 13:38:04 UTC
hello? ping?
Comment 5 Vlastimil Babka 2017-03-03 09:39:28 UTC
Observations:

- RH bug https://bugzilla.redhat.com/show_bug.cgi?id=1308846 doesn't have any detail. There's mention of another bug https://bugzilla.redhat.com/show_bug.cgi?id=1306851 which should even have a reproducer, but that wants a login some access privileges. Do we have such account on RH bugzilla?

- affected kernels should be SLE12 and SLE12-SP1

- based on the scarce information, it seems the problem is when account_page_dirtied() is called with a mapping where mapping->backing_dev_info->dev is NULL, and the writeback_dirty_page tracepoint is enabled. Then trace_writeback_dirty_page() will try to extract name of the dev via dev_name(mapping->backing_dev_info->dev). dev_name() doesn't expect dev to be NULL and dereferences dev->init_name.

- RH bug mentions aio_fs_backing_dev_info, but it seems there are few more bdi types that have the following properties:
  - no bdi.dev assigned, thus NULL
  - bdi.capabilities includes BDI_CAP_NO_ACCT_AND_WRITEBACK which means no dirty page accounting and no page writeback
  - mapping->a_ops->set_page_dirty is set to e.g. __set_page_dirty_no_writeback or some other implementation, that doesn't call account_page_dirtied() (i.e. not __set_page_dirty_nobuffers)

- This means account_page_dirtied() shouldn't be called for pages with such mapping->bdi.

- migrate_page_copy() breaks this assumption by calling __set_page_dirty_nobuffers(newpage), thus account_page_dirtied()

How to fix this?

- upstream commit http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=42cb14b110a5698ccf26ce59c4441722605a3743 has fixed this just accidentally, changelog says "No actual problems seen with this procedure recently". It does seem like the best long-term fix, as it fixes migrate_page_copy() doing some arbitrary fixups that are different from a_ops->set_page_dirty. But the patch is part of 12-patch series and could be a risk to backport even if it turns out to be stand-alone.

- we could patch account_page_dirtied() to only call the tracepoint inside the "if (mapping_cap_account_dirty(mapping))" branch, which will exclude bdi's with BDI_CAP_NO_ACCT_AND_WRITEBACK. Upstream might not accept such patch without an actual upstream problem, but we might argue that it doesn't make sense to trace events that actually do nothing.

- we could patch the tracepoint to be more careful and check dev != NULL first. Upstream might see this as pointless overhead.

Michal, what do you think?
Comment 6 Vlastimil Babka 2017-03-06 07:57:14 UTC
(In reply to Vlastimil Babka from comment #5)
> - upstream commit
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=42cb14b110a5698ccf26ce59c4441722605a3743 has fixed this just
> accidentally, changelog says "No actual problems seen with this procedure
> recently". It does seem like the best long-term fix, as it fixes
> migrate_page_copy() doing some arbitrary fixups that are different from
> a_ops->set_page_dirty. But the patch is part of 12-patch series and could be
> a risk to backport even if it turns out to be stand-alone.

Ah, it seems the commit was later backported to stable kernels including 3.12, so SLE12-SP1 has it since August. So I guess we just apply the same to SLE12-LTSS, unless the CVE score / priority is below LTSS threshold or something?
Comment 12 Swamp Workflow Management 2017-05-11 19:14:30 UTC
SUSE-SU-2017:1247-1: An update that solves 25 vulnerabilities and has 10 fixes is now available.

Category: security (important)
Bug References: 1003077,1015703,1021256,1021762,1023377,1023762,1023992,1024938,1025235,1026024,1026722,1026914,1027066,1027149,1027178,1027189,1027190,1028415,1028895,1029986,1030118,1030213,1030901,1031003,1031052,1031440,1031579,1032344,1033336,914939,954763,968697,979215,983212,989056
CVE References: CVE-2015-1350,CVE-2016-10044,CVE-2016-10200,CVE-2016-10208,CVE-2016-2117,CVE-2016-3070,CVE-2016-5243,CVE-2016-7117,CVE-2016-9588,CVE-2017-2671,CVE-2017-5669,CVE-2017-5897,CVE-2017-5970,CVE-2017-5986,CVE-2017-6074,CVE-2017-6214,CVE-2017-6345,CVE-2017-6346,CVE-2017-6348,CVE-2017-6353,CVE-2017-7187,CVE-2017-7261,CVE-2017-7294,CVE-2017-7308,CVE-2017-7616
Sources used:
SUSE Linux Enterprise Server for SAP 12 (src):    kernel-default-3.12.61-52.72.1, kernel-source-3.12.61-52.72.1, kernel-syms-3.12.61-52.72.1, kernel-xen-3.12.61-52.72.1, kgraft-patch-SLE12_Update_21-1-2.1
SUSE Linux Enterprise Server 12-LTSS (src):    kernel-default-3.12.61-52.72.1, kernel-source-3.12.61-52.72.1, kernel-syms-3.12.61-52.72.1, kernel-xen-3.12.61-52.72.1, kgraft-patch-SLE12_Update_21-1-2.1
SUSE Linux Enterprise Module for Public Cloud 12 (src):    kernel-ec2-3.12.61-52.72.1
Comment 13 Swamp Workflow Management 2017-05-19 16:25:47 UTC
SUSE-SU-2017:1360-1: An update that solves 30 vulnerabilities and has 72 fixes is now available.

Category: security (important)
Bug References: 1003077,1008842,1009682,1012620,1012985,1015703,1015787,1015821,1017512,1018100,1018263,1018419,1018446,1019168,1019514,1020048,1020795,1021256,1021374,1021762,1021913,1022559,1022971,1023164,1023207,1023377,1023762,1023824,1023888,1023992,1024081,1024234,1024309,1024508,1024788,1025039,1025235,1025354,1025802,1026024,1026722,1026914,1027066,1027178,1027189,1027190,1027974,1028041,1028415,1028595,1028648,1028895,1029470,1029850,1029986,1030118,1030213,1030593,1030901,1031003,1031052,1031080,1031440,1031567,1031579,1031662,1031842,1032125,1032141,1032344,1032345,1033336,1034670,103470,1034700,1035576,1035699,1035738,1035877,1036752,1038261,799133,857926,914939,917630,922853,930399,931620,937444,940946,954763,968697,970083,971933,979215,982783,983212,984530,985561,988065,989056,993832
CVE References: CVE-2015-1350,CVE-2016-10044,CVE-2016-10200,CVE-2016-10208,CVE-2016-2117,CVE-2016-3070,CVE-2016-5243,CVE-2016-7117,CVE-2016-9191,CVE-2016-9588,CVE-2016-9604,CVE-2017-2647,CVE-2017-2671,CVE-2017-5669,CVE-2017-5897,CVE-2017-5986,CVE-2017-6074,CVE-2017-6214,CVE-2017-6345,CVE-2017-6346,CVE-2017-6348,CVE-2017-6353,CVE-2017-6951,CVE-2017-7187,CVE-2017-7261,CVE-2017-7294,CVE-2017-7308,CVE-2017-7616,CVE-2017-7645,CVE-2017-8106
Sources used:
SUSE Linux Enterprise Workstation Extension 12-SP1 (src):    kernel-default-3.12.74-60.64.40.1
SUSE Linux Enterprise Software Development Kit 12-SP1 (src):    kernel-docs-3.12.74-60.64.40.4, kernel-obs-build-3.12.74-60.64.40.1
SUSE Linux Enterprise Server 12-SP1 (src):    kernel-default-3.12.74-60.64.40.1, kernel-source-3.12.74-60.64.40.1, kernel-syms-3.12.74-60.64.40.1, kernel-xen-3.12.74-60.64.40.1
SUSE Linux Enterprise Module for Public Cloud 12 (src):    kernel-ec2-3.12.74-60.64.40.1
SUSE Linux Enterprise Live Patching 12 (src):    kgraft-patch-SLE12-SP1_Update_15-1-4.1
SUSE Linux Enterprise Desktop 12-SP1 (src):    kernel-default-3.12.74-60.64.40.1, kernel-source-3.12.74-60.64.40.1, kernel-syms-3.12.74-60.64.40.1, kernel-xen-3.12.74-60.64.40.1
Comment 14 Marcus Meissner 2018-02-09 06:14:48 UTC
released