diff --git a/Documentation/process/embargoed-hardware-issues.rst b/Documentation/process/embargoed-hardware-issues.rst index df97812..cb68623 100644 --- a/Documentation/process/embargoed-hardware-issues.rst +++ b/Documentation/process/embargoed-hardware-issues.rst @@ -254,7 +254,6 @@ an involved disclosed party. The current ambassadors list: Samsung Javier González Microsoft James Morris - VMware Xen Andrew Cooper Canonical John Johansen @@ -263,10 +262,8 @@ an involved disclosed party. The current ambassadors list: Red Hat Josh Poimboeuf SUSE Jiri Kosina - Amazon Google Kees Cook - GCC LLVM Nick Desaulniers ============= ======================================================== diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index 82e2983..5a69937 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -63,31 +63,28 @@ information submitted to the security list and any followup discussions of the report are treated confidentially even after the embargo has been lifted, in perpetuity. -Coordination ------------- - -Fixes for sensitive bugs, such as those that might lead to privilege -escalations, may need to be coordinated with the private - mailing list so that distribution vendors -are well prepared to issue a fixed kernel upon public disclosure of the -upstream fix. Distros will need some time to test the proposed patch and -will generally request at least a few days of embargo, and vendor update -publication prefers to happen Tuesday through Thursday. When appropriate, -the security team can assist with this coordination, or the reporter can -include linux-distros from the start. In this case, remember to prefix -the email Subject line with "[vs]" as described in the linux-distros wiki: - +Coordination with other groups +------------------------------ + +The kernel security team strongly recommends that reporters of potential +security issues NEVER contact the "linux-distros" mailing list until +AFTER discussing it with the kernel security team. Do not Cc: both +lists at once. You may contact the linux-distros mailing list after a +fix has been agreed on and you fully understand the requirements that +doing so will impose on you and the kernel community. + +The different lists have different goals and the linux-distros rules do +not contribute to actually fixing any potential security problems. CVE assignment -------------- -The security team does not normally assign CVEs, nor do we require them -for reports or fixes, as this can needlessly complicate the process and -may delay the bug handling. If a reporter wishes to have a CVE identifier -assigned ahead of public disclosure, they will need to contact the private -linux-distros list, described above. When such a CVE identifier is known -before a patch is provided, it is desirable to mention it in the commit -message if the reporter agrees. +The security team does not assign CVEs, nor do we require them for +reports or fixes, as this can needlessly complicate the process and may +delay the bug handling. If a reporter wishes to have a CVE identifier +assigned, they should find one by themselves, for example by contacting +MITRE directly. However under no circumstances will a patch inclusion +be delayed to wait for a CVE identifier to arrive. Non-disclosure agreements ------------------------- diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c index 5757adf..6120973 100644 --- a/drivers/misc/sram.c +++ b/drivers/misc/sram.c @@ -236,7 +236,7 @@ static int sram_reserve_regions(struct sram_dev *sram, struct resource *res) } if (!label) block->label = devm_kasprintf(sram->dev, GFP_KERNEL, - "%s", dev_name(sram->dev)); + "%s", of_node_full_name(child)); else block->label = devm_kstrdup(sram->dev, label, GFP_KERNEL); diff --git a/lib/genalloc.c b/lib/genalloc.c index 0c883d6..6c644f9 100644 --- a/lib/genalloc.c +++ b/lib/genalloc.c @@ -895,7 +895,7 @@ struct gen_pool *of_gen_pool_get(struct device_node *np, of_property_read_string(np_pool, "label", &name); if (!name) - name = np_pool->name; + name = of_node_full_name(np_pool); } if (pdev) pool = gen_pool_get(&pdev->dev, name);