system/linux
system/linux
1
0
Fork 0
mirror of https://github.com/torvalds/linux synced 2024-10-14 23:39:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

Char driver and Documentation fixes for 6.5-rc4

Browse source 
Here is a char driver fix and some documentation updates for 6.5-rc4
 that contain the following changes:
   - sram/genalloc bugfix for reported problem
   - security-bugs.rst update based on recent discussions
   - embargoed-hardware-issues minor cleanups and then partial revert for
     the project/company lists
 
 All of these have been in linux-next for a while with no reported
 problems, and the documentation updates have all been reviewed by the
 relevant developers.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 
 iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCZMZD6A8cZ3JlZ0Brcm9h
 aC5jb20ACgkQMUfUDdst+ynxZACgksV7C7yJWTm9UfZNZ2ABUhj69aEAnR/X9tLr
 Sjtjo0iaoAZpE+2tjHt1
 =J/gW
 -----END PGP SIGNATURE-----

Merge tag 'char-misc-6.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

Pull char driver and Documentation fixes from Greg KH:
 "Here is a char driver fix and some documentation updates for 6.5-rc4
  that contain the following changes:

   - sram/genalloc bugfix for reported problem

   - security-bugs.rst update based on recent discussions

   - embargoed-hardware-issues minor cleanups and then partial revert
     for the project/company lists

  All of these have been in linux-next for a while with no reported
  problems, and the documentation updates have all been reviewed by the
  relevant developers"

* tag 'char-misc-6.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  misc/genalloc: Name subpools by of_node_full_name()
  Documentation: embargoed-hardware-issues.rst: add AMD to the list
  Documentation: embargoed-hardware-issues.rst: clean out empty and unused entries
  Documentation: security-bugs.rst: clarify CVE handling
  Documentation: security-bugs.rst: update preferences when dealing with the linux-distros group
This commit is contained in:
Linus Torvalds 2023-07-30 11:44:00 -07:00
parent b0b9850e7d f8ea950210
commit cf270e7b75
4 changed files with 19 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
Documentation/process/embargoed-hardware-issues.rst
View file

@ -254,7 +254,6 @@ an involved disclosed party. The current ambassadors list:
Samsung Javier González <javier.gonz@samsung.com>
Microsoft James Morris <jamorris@linux.microsoft.com>
VMware
Xen Andrew Cooper <andrew.cooper3@citrix.com>
Canonical John Johansen <john.johansen@canonical.com>
@ -263,10 +262,8 @@ an involved disclosed party. The current ambassadors list:
Red Hat Josh Poimboeuf <jpoimboe@redhat.com>
SUSE Jiri Kosina <jkosina@suse.cz>
Amazon
Google Kees Cook <keescook@chromium.org>
GCC
LLVM Nick Desaulniers <ndesaulniers@google.com>
============= ========================================================

37
Documentation/process/security-bugs.rst
View file

@ -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
------------
Coordination with other groups
------------------------------
Fixes for sensitive bugs, such as those that might lead to privilege
escalations, may need to be coordinated with the private
<linux-distros@vs.openwall.org> 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:
<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
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
-------------------------

2
drivers/misc/sram.c
View file

@ -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);

2
lib/genalloc.c
View file

@ -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);