tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Merge tag 'driver-core-6.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

Pull driver core fixes from Greg KH:
"Here are some driver core fixes, a kobject fix, and a documentation
update for 6.8-rc5. In detail these changes are:

- devlink fixes for reported issues with 6.8-rc1

- topology scheduling regression fix that has been reported by many

- kobject loosening of checks change in -rc1 is now reverted as some
codepaths seemed to need the checks

- documentation update for the CVE process. Has been reviewed by
many, the last minute change to the document was to bring the .rst
format back into the the new style rules, the contents did not
change.

All of these, except for the documentation update, have been in
linux-next for over a week. The documentation update has been reviewed
for weeks by a group of developers, and in public for a week and the
wording has stabilized for now. If future changes are needed, we can
do so before 6.8-final is out (or anytime after that)"

* tag 'driver-core-6.8-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
Documentation: Document the Linux Kernel CVE process
Revert "kobject: Remove redundant checks for whether ktype is NULL"
driver core: fw_devlink: Improve logs for cycle detection
driver core: fw_devlink: Improve detection of overlapping cycles
driver core: Fix device_link_flag_is_sync_state_only()
topology: Set capacity_freq_ref in all cases

Linus Torvalds ced59052 7efc0eb8

+169 -26
+121
Documentation/process/cve.rst
··· 1 + ==== 2 + CVEs 3 + ==== 4 + 5 + Common Vulnerabilities and Exposure (CVE®) numbers were developed as an 6 + unambiguous way to identify, define, and catalog publicly disclosed 7 + security vulnerabilities. Over time, their usefulness has declined with 8 + regards to the kernel project, and CVE numbers were very often assigned 9 + in inappropriate ways and for inappropriate reasons. Because of this, 10 + the kernel development community has tended to avoid them. However, the 11 + combination of continuing pressure to assign CVEs and other forms of 12 + security identifiers, and ongoing abuses by individuals and companies 13 + outside of the kernel community has made it clear that the kernel 14 + community should have control over those assignments. 15 + 16 + The Linux kernel developer team does have the ability to assign CVEs for 17 + potential Linux kernel security issues. This assignment is independent 18 + of the :doc:`normal Linux kernel security bug reporting 19 + process<../process/security-bugs>`. 20 + 21 + A list of all assigned CVEs for the Linux kernel can be found in the 22 + archives of the linux-cve mailing list, as seen on 23 + https://lore.kernel.org/linux-cve-announce/. To get notice of the 24 + assigned CVEs, please `subscribe 25 + <https://subspace.kernel.org/subscribing.html>`_ to that mailing list. 26 + 27 + Process 28 + ======= 29 + 30 + As part of the normal stable release process, kernel changes that are 31 + potentially security issues are identified by the developers responsible 32 + for CVE number assignments and have CVE numbers automatically assigned 33 + to them. These assignments are published on the linux-cve-announce 34 + mailing list as announcements on a frequent basis. 35 + 36 + Note, due to the layer at which the Linux kernel is in a system, almost 37 + any bug might be exploitable to compromise the security of the kernel, 38 + but the possibility of exploitation is often not evident when the bug is 39 + fixed. Because of this, the CVE assignment team is overly cautious and 40 + assign CVE numbers to any bugfix that they identify. This 41 + explains the seemingly large number of CVEs that are issued by the Linux 42 + kernel team. 43 + 44 + If the CVE assignment team misses a specific fix that any user feels 45 + should have a CVE assigned to it, please email them at <cve@kernel.org> 46 + and the team there will work with you on it. Note that no potential 47 + security issues should be sent to this alias, it is ONLY for assignment 48 + of CVEs for fixes that are already in released kernel trees. If you 49 + feel you have found an unfixed security issue, please follow the 50 + :doc:`normal Linux kernel security bug reporting 51 + process<../process/security-bugs>`. 52 + 53 + No CVEs will be automatically assigned for unfixed security issues in 54 + the Linux kernel; assignment will only automatically happen after a fix 55 + is available and applied to a stable kernel tree, and it will be tracked 56 + that way by the git commit id of the original fix. If anyone wishes to 57 + have a CVE assigned before an issue is resolved with a commit, please 58 + contact the kernel CVE assignment team at <cve@kernel.org> to get an 59 + identifier assigned from their batch of reserved identifiers. 60 + 61 + No CVEs will be assigned for any issue found in a version of the kernel 62 + that is not currently being actively supported by the Stable/LTS kernel 63 + team. A list of the currently supported kernel branches can be found at 64 + https://kernel.org/releases.html 65 + 66 + Disputes of assigned CVEs 67 + ========================= 68 + 69 + The authority to dispute or modify an assigned CVE for a specific kernel 70 + change lies solely with the maintainers of the relevant subsystem 71 + affected. This principle ensures a high degree of accuracy and 72 + accountability in vulnerability reporting. Only those individuals with 73 + deep expertise and intimate knowledge of the subsystem can effectively 74 + assess the validity and scope of a reported vulnerability and determine 75 + its appropriate CVE designation. Any attempt to modify or dispute a CVE 76 + outside of this designated authority could lead to confusion, inaccurate 77 + reporting, and ultimately, compromised systems. 78 + 79 + Invalid CVEs 80 + ============ 81 + 82 + If a security issue is found in a Linux kernel that is only supported by 83 + a Linux distribution due to the changes that have been made by that 84 + distribution, or due to the distribution supporting a kernel version 85 + that is no longer one of the kernel.org supported releases, then a CVE 86 + can not be assigned by the Linux kernel CVE team, and must be asked for 87 + from that Linux distribution itself. 88 + 89 + Any CVE that is assigned against the Linux kernel for an actively 90 + supported kernel version, by any group other than the kernel assignment 91 + CVE team should not be treated as a valid CVE. Please notify the 92 + kernel CVE assignment team at <cve@kernel.org> so that they can work to 93 + invalidate such entries through the CNA remediation process. 94 + 95 + Applicability of specific CVEs 96 + ============================== 97 + 98 + As the Linux kernel can be used in many different ways, with many 99 + different ways of accessing it by external users, or no access at all, 100 + the applicability of any specific CVE is up to the user of Linux to 101 + determine, it is not up to the CVE assignment team. Please do not 102 + contact us to attempt to determine the applicability of any specific 103 + CVE. 104 + 105 + Also, as the source tree is so large, and any one system only uses a 106 + small subset of the source tree, any users of Linux should be aware that 107 + large numbers of assigned CVEs are not relevant for their systems. 108 + 109 + In short, we do not know your use case, and we do not know what portions 110 + of the kernel that you use, so there is no way for us to determine if a 111 + specific CVE is relevant for your system. 112 + 113 + As always, it is best to take all released kernel changes, as they are 114 + tested together in a unified whole by many community members, and not as 115 + individual cherry-picked changes. Also note that for many bugs, the 116 + solution to the overall problem is not found in a single change, but by 117 + the sum of many fixes on top of each other. Ideally CVEs will be 118 + assigned to all fixes for all issues, but sometimes we will fail to 119 + notice fixes, therefore assume that some changes without a CVE assigned 120 + might be relevant to take. 121 +
+1
Documentation/process/index.rst
··· 81 81 82 82 handling-regressions 83 83 security-bugs 84 + cve 84 85 embargoed-hardware-issues 85 86 86 87 Maintainer information
+2 -3
Documentation/process/security-bugs.rst
··· 99 99 The security team does not assign CVEs, nor do we require them for 100 100 reports or fixes, as this can needlessly complicate the process and may 101 101 delay the bug handling. If a reporter wishes to have a CVE identifier 102 - assigned, they should find one by themselves, for example by contacting 103 - MITRE directly. However under no circumstances will a patch inclusion 104 - be delayed to wait for a CVE identifier to arrive. 102 + assigned for a confirmed issue, they can contact the :doc:`kernel CVE 103 + assignment team<../process/cve>` to obtain one. 105 104 106 105 Non-disclosure agreements 107 106 -------------------------
+5
MAINTAINERS
··· 5610 5610 F: Documentation/devicetree/bindings/net/can/ctu,ctucanfd.yaml 5611 5611 F: drivers/net/can/ctucanfd/ 5612 5612 5613 + CVE ASSIGNMENT CONTACT 5614 + M: CVE Assignment Team <cve@kernel.org> 5615 + S: Maintained 5616 + F: Documentation/process/cve.rst 5617 + 5613 5618 CW1200 WLAN driver 5614 5619 S: Orphan 5615 5620 F: drivers/net/wireless/st/cw1200/
+6 -7
drivers/base/arch_topology.c
··· 431 431 struct cpufreq_policy *policy = data; 432 432 int cpu; 433 433 434 - if (!raw_capacity) 435 - return 0; 436 - 437 434 if (val != CPUFREQ_CREATE_POLICY) 438 435 return 0; 439 436 ··· 447 450 } 448 451 449 452 if (cpumask_empty(cpus_to_visit)) { 450 - topology_normalize_cpu_scale(); 451 - schedule_work(&update_topology_flags_work); 452 - free_raw_capacity(); 453 + if (raw_capacity) { 454 + topology_normalize_cpu_scale(); 455 + schedule_work(&update_topology_flags_work); 456 + free_raw_capacity(); 457 + } 453 458 pr_debug("cpu_capacity: parsing done\n"); 454 459 schedule_work(&parsing_done_work); 455 460 } ··· 471 472 * On ACPI-based systems skip registering cpufreq notifier as cpufreq 472 473 * information is not needed for cpu capacity initialization. 473 474 */ 474 - if (!acpi_disabled || !raw_capacity) 475 + if (!acpi_disabled) 475 476 return -EINVAL; 476 477 477 478 if (!alloc_cpumask_var(&cpus_to_visit, GFP_KERNEL))
+20 -6
drivers/base/core.c
··· 125 125 */ 126 126 static void __fwnode_link_cycle(struct fwnode_link *link) 127 127 { 128 - pr_debug("%pfwf: Relaxing link with %pfwf\n", 128 + pr_debug("%pfwf: cycle: depends on %pfwf\n", 129 129 link->consumer, link->supplier); 130 130 link->flags |= FWLINK_FLAG_CYCLE; 131 131 } ··· 284 284 return false; 285 285 } 286 286 287 + #define DL_MARKER_FLAGS (DL_FLAG_INFERRED | \ 288 + DL_FLAG_CYCLE | \ 289 + DL_FLAG_MANAGED) 287 290 static inline bool device_link_flag_is_sync_state_only(u32 flags) 288 291 { 289 - return (flags & ~(DL_FLAG_INFERRED | DL_FLAG_CYCLE)) == 290 - (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED); 292 + return (flags & ~DL_MARKER_FLAGS) == DL_FLAG_SYNC_STATE_ONLY; 291 293 } 292 294 293 295 /** ··· 1945 1943 1946 1944 /* Termination condition. */ 1947 1945 if (sup_dev == con) { 1946 + pr_debug("----- cycle: start -----\n"); 1948 1947 ret = true; 1949 1948 goto out; 1950 1949 } ··· 1977 1974 else 1978 1975 par_dev = fwnode_get_next_parent_dev(sup_handle); 1979 1976 1980 - if (par_dev && __fw_devlink_relax_cycles(con, par_dev->fwnode)) 1977 + if (par_dev && __fw_devlink_relax_cycles(con, par_dev->fwnode)) { 1978 + pr_debug("%pfwf: cycle: child of %pfwf\n", sup_handle, 1979 + par_dev->fwnode); 1981 1980 ret = true; 1981 + } 1982 1982 1983 1983 if (!sup_dev) 1984 1984 goto out; ··· 1997 1991 1998 1992 if (__fw_devlink_relax_cycles(con, 1999 1993 dev_link->supplier->fwnode)) { 1994 + pr_debug("%pfwf: cycle: depends on %pfwf\n", sup_handle, 1995 + dev_link->supplier->fwnode); 2000 1996 fw_devlink_relax_link(dev_link); 2001 1997 dev_link->flags |= DL_FLAG_CYCLE; 2002 1998 ret = true; ··· 2066 2058 2067 2059 /* 2068 2060 * SYNC_STATE_ONLY device links don't block probing and supports cycles. 2069 - * So cycle detection isn't necessary and shouldn't be done. 2061 + * So, one might expect that cycle detection isn't necessary for them. 2062 + * However, if the device link was marked as SYNC_STATE_ONLY because 2063 + * it's part of a cycle, then we still need to do cycle detection. This 2064 + * is because the consumer and supplier might be part of multiple cycles 2065 + * and we need to detect all those cycles. 2070 2066 */ 2071 - if (!(flags & DL_FLAG_SYNC_STATE_ONLY)) { 2067 + if (!device_link_flag_is_sync_state_only(flags) || 2068 + flags & DL_FLAG_CYCLE) { 2072 2069 device_links_write_lock(); 2073 2070 if (__fw_devlink_relax_cycles(con, sup_handle)) { 2074 2071 __fwnode_link_cycle(link); 2075 2072 flags = fw_devlink_get_flags(link->flags); 2073 + pr_debug("----- cycle: end -----\n"); 2076 2074 dev_info(con, "Fixed dependency cycle(s) with %pfwf\n", 2077 2075 sup_handle); 2078 2076 }
+14 -10
lib/kobject.c
··· 74 74 if (error) 75 75 return error; 76 76 77 - error = sysfs_create_groups(kobj, ktype->default_groups); 78 - if (error) { 79 - sysfs_remove_dir(kobj); 80 - return error; 77 + if (ktype) { 78 + error = sysfs_create_groups(kobj, ktype->default_groups); 79 + if (error) { 80 + sysfs_remove_dir(kobj); 81 + return error; 82 + } 81 83 } 82 84 83 85 /* ··· 591 589 sd = kobj->sd; 592 590 ktype = get_ktype(kobj); 593 591 594 - sysfs_remove_groups(kobj, ktype->default_groups); 592 + if (ktype) 593 + sysfs_remove_groups(kobj, ktype->default_groups); 595 594 596 595 /* send "remove" if the caller did not do it but sent "add" */ 597 596 if (kobj->state_add_uevent_sent && !kobj->state_remove_uevent_sent) { ··· 669 666 pr_debug("'%s' (%p): %s, parent %p\n", 670 667 kobject_name(kobj), kobj, __func__, kobj->parent); 671 668 669 + if (t && !t->release) 670 + pr_debug("'%s' (%p): does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst.\n", 671 + kobject_name(kobj), kobj); 672 + 672 673 /* remove from sysfs if the caller did not do it */ 673 674 if (kobj->state_in_sysfs) { 674 675 pr_debug("'%s' (%p): auto cleanup kobject_del\n", ··· 683 676 parent = NULL; 684 677 } 685 678 686 - if (t->release) { 679 + if (t && t->release) { 687 680 pr_debug("'%s' (%p): calling ktype release\n", 688 681 kobject_name(kobj), kobj); 689 682 t->release(kobj); 690 - } else { 691 - pr_debug("'%s' (%p): does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst.\n", 692 - kobject_name(kobj), kobj); 693 683 } 694 684 695 685 /* free name if we allocated it */ ··· 1060 1056 { 1061 1057 const struct kobj_ns_type_operations *ops = NULL; 1062 1058 1063 - if (parent && parent->ktype->child_ns_type) 1059 + if (parent && parent->ktype && parent->ktype->child_ns_type) 1064 1060 ops = parent->ktype->child_ns_type(parent); 1065 1061 1066 1062 return ops;