Vulnerabilities

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 /> 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: 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 /> 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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: media: max96712: fix kernel oops when removing module<br /> <br /> The following kernel oops is thrown when trying to remove the max96712<br /> module:<br /> <br /> Unable to handle kernel paging request at virtual address 00007375746174db<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000<br /> [00007375746174db] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan<br /> snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2<br /> imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev<br /> snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils<br /> max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse<br /> [last unloaded: imx8_isi]<br /> CPU: 0 UID: 0 PID: 754 Comm: rmmod<br /> Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17<br /> Tainted: [C]=CRAP<br /> Hardware name: NXP i.MX95 19X19 board (DT)<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : led_put+0x1c/0x40<br /> lr : v4l2_subdev_put_privacy_led+0x48/0x58<br /> sp : ffff80008699bbb0<br /> x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8<br /> x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000<br /> x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010<br /> x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d<br /> x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1<br /> x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473<br /> Call trace:<br /> led_put+0x1c/0x40<br /> v4l2_subdev_put_privacy_led+0x48/0x58<br /> v4l2_async_unregister_subdev+0x2c/0x1a4<br /> max96712_remove+0x1c/0x38 [max96712]<br /> i2c_device_remove+0x2c/0x9c<br /> device_remove+0x4c/0x80<br /> device_release_driver_internal+0x1cc/0x228<br /> driver_detach+0x4c/0x98<br /> bus_remove_driver+0x6c/0xbc<br /> driver_unregister+0x30/0x60<br /> i2c_del_driver+0x54/0x64<br /> max96712_i2c_driver_exit+0x18/0x1d0 [max96712]<br /> __arm64_sys_delete_module+0x1a4/0x290<br /> invoke_syscall+0x48/0x10c<br /> el0_svc_common.constprop.0+0xc0/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x34/0xd8<br /> el0t_64_sync_handler+0x120/0x12c<br /> el0t_64_sync+0x190/0x194<br /> Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata()<br /> is called again and the data is overwritten to point to sd, instead of<br /> priv. So, in remove(), the wrong pointer is passed to<br /> v4l2_async_unregister_subdev(), leading to a crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi: ipmb: Add check devm_kasprintf() returned value<br /> <br /> devm_kasprintf() can return a NULL pointer on failure but this<br /> returned value is not checked.