Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: remove unused check_buddy_priv<br /> <br /> Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global<br /> list of private data structures.<br /> <br /> Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match<br /> vendor version 2013.02.07") started adding the private data to that list at<br /> probe time and added a hook, check_buddy_priv to find the private data from<br /> a similar device.<br /> <br /> However, that function was never used.<br /> <br /> Besides, though there is a lock for that list, it is never used. And when<br /> the probe fails, the private data is never removed from the list. This<br /> would cause a second probe to access freed memory.<br /> <br /> Remove the unused hook, structures and members, which will prevent the<br /> potential race condition on the list and its corruption during a second<br /> probe when probe fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Fix deadlock during uvc_probe<br /> <br /> If uvc_probe() fails, it can end up calling uvc_status_unregister() before<br /> uvc_status_init() is called.<br /> <br /> Fix this by checking if dev-&gt;status is NULL or not in<br /> uvc_status_unregister().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing<br /> <br /> There is a UAF report in the bpf_struct_ops when CONFIG_MODULES=n.<br /> In particular, the report is on tcp_congestion_ops that has<br /> a "struct module *owner" member.<br /> <br /> For struct_ops that has a "struct module *owner" member,<br /> it can be extended either by the regular kernel module or<br /> by the bpf_struct_ops. bpf_try_module_get() will be used<br /> to do the refcounting and different refcount is done<br /> based on the owner pointer. When CONFIG_MODULES=n,<br /> the btf_id of the "struct module" is missing:<br /> <br /> WARN: resolve_btfids: unresolved symbol module<br /> <br /> Thus, the bpf_try_module_get() cannot do the correct refcounting.<br /> <br /> Not all subsystem&amp;#39;s struct_ops requires the "struct module *owner" member.<br /> e.g. the recent sched_ext_ops.<br /> <br /> This patch is to disable bpf_struct_ops registration if<br /> the struct_ops has the "struct module *" member and the<br /> "struct module" btf_id is missing. The btf_type_is_fwd() helper<br /> is moved to the btf.h header file for this test.<br /> <br /> This has happened since the beginning of bpf_struct_ops which has gone<br /> through many changes. The Fixes tag is set to a recent commit that this<br /> patch can apply cleanly. Considering CONFIG_MODULES=n is not<br /> common and the age of the issue, targeting for bpf-next also.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: avoid NULL pointer dereference<br /> <br /> When iterating over the links of a vif, we need to make sure that the<br /> pointer is valid (in other words - that the link exists) before<br /> dereferncing it.<br /> Use for_each_vif_active_link that also does the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: tests: Fix potential NULL dereference in test_cfg80211_parse_colocated_ap()<br /> <br /> kunit_kzalloc() may return NULL, dereferencing it without NULL check may<br /> lead to NULL dereference.<br /> Add a NULL check for ies.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mmp: pxa1908-apbc: Fix NULL vs IS_ERR() check<br /> <br /> The devm_kzalloc() function returns NULL on error, not error pointers.<br /> Fix the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mmp: pxa1908-apbcp: Fix a NULL vs IS_ERR() check<br /> <br /> The devm_kzalloc() function doesn&amp;#39;t return error pointers, it returns<br /> NULL on error. Update the check to match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: prohibit deactivating all links<br /> <br /> In the internal API this calls this is a WARN_ON, but that<br /> should remain since internally we want to know about bugs<br /> that may cause this. Prevent deactivating all links in the<br /> debugfs write directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: skip dumping tnc tree when zroot is null<br /> <br /> Clearing slab cache will free all znode in memory and make<br /> c-&gt;zroot.znode = NULL, then dumping tnc tree will access<br /> c-&gt;zroot.znode which cause null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: fix memory leaks and invalid access at probe error path<br /> <br /> Deinitialize at reverse order when probe fails.<br /> <br /> When init_sw_vars fails, rtl_deinit_core should not be called, specially<br /> now that it destroys the rtl_wq workqueue.<br /> <br /> And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be<br /> leaked.<br /> <br /> Remove pci_set_drvdata call as it will already be cleaned up by the core<br /> driver code and could lead to memory leaks too. cf. commit 8d450935ae7f<br /> ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and<br /> commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: convert workqueues to unbound<br /> <br /> When a workqueue is created with `WQ_UNBOUND`, its work items are<br /> served by special worker-pools, whose host workers are not bound to<br /> any specific CPU. In the default configuration (i.e. when<br /> `queue_delayed_work` and friends do not specify which CPU to run the<br /> work item on), `WQ_UNBOUND` allows the work item to be executed on any<br /> CPU in the same node of the CPU it was enqueued on. While this<br /> solution potentially sacrifices locality, it avoids contention with<br /> other processes that might dominate the CPU time of the processor the<br /> work item was scheduled on.<br /> <br /> This is not just a theoretical problem: in a particular scenario<br /> misconfigured process was hogging most of the time from CPU0, leaving<br /> less than 0.5% of its CPU time to the kworker. The IDPF workqueues<br /> that were using the kworker on CPU0 suffered large completion delays<br /> as a result, causing performance degradation, timeouts and eventual<br /> system crash.<br /> <br /> <br /> * I have also run a manual test to gauge the performance<br /> improvement. The test consists of an antagonist process<br /> (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This<br /> process is run under `taskset 01` to bind it to CPU0, and its<br /> priority is changed with `chrt -pQ 9900 10000 ${pid}` and<br /> `renice -n -20 ${pid}` after start.<br /> <br /> Then, the IDPF driver is forced to prefer CPU0 by editing all calls<br /> to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0.<br /> <br /> Finally, `ktraces` for the workqueue events are collected.<br /> <br /> Without the current patch, the antagonist process can force<br /> arbitrary delays between `workqueue_queue_work` and<br /> `workqueue_execute_start`, that in my tests were as high as<br /> `30ms`. With the current patch applied, the workqueue can be<br /> migrated to another unloaded CPU in the same node, and, keeping<br /> everything else equal, the maximum delay I could see was `6us`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix handling of received connection abort<br /> <br /> Fix the handling of a connection abort that we&amp;#39;ve received. Though the<br /> abort is at the connection level, it needs propagating to the calls on that<br /> connection. Whilst the propagation bit is performed, the calls aren&amp;#39;t then<br /> woken up to go and process their termination, and as no further input is<br /> forthcoming, they just hang.<br /> <br /> Also add some tracing for the logging of connection aborts.