Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix not cleanup led when bt_init fails<br /> <br /> bt_init() calls bt_leds_init() to register led, but if it fails later,<br /> bt_leds_cleanup() is not called to unregister it.<br /> <br /> This can cause panic if the argument "bluetooth-power" in text is freed<br /> and then another led_trigger_register() tries to access it:<br /> <br /> BUG: unable to handle page fault for address: ffffffffc06d3bc0<br /> RIP: 0010:strcmp+0xc/0x30<br /> Call Trace:<br /> <br /> led_trigger_register+0x10d/0x4f0<br /> led_trigger_register_simple+0x7d/0x100<br /> bt_init+0x39/0xf7 [bluetooth]<br /> do_one_initcall+0xd0/0x4e0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()<br /> <br /> Kernel fault injection test reports null-ptr-deref as follows:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114<br /> Call Trace:<br /> <br /> raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87<br /> call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944<br /> unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982<br /> unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879<br /> register_netdevice+0x9a8/0xb90 net/core/dev.c:10083<br /> ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659<br /> ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229<br /> mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316<br /> <br /> ieee802154_if_add() allocates wpan_dev as netdev&amp;#39;s private data, but not<br /> init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage<br /> the list when device register/unregister, and may lead to null-ptr-deref.<br /> <br /> Use INIT_LIST_HEAD() on it to initialize it correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: amd8111: Fix PCI device reference count leak<br /> <br /> for_each_pci_dev() is implemented by pci_get_device(). The comment of<br /> pci_get_device() says that it will increase the reference count for the<br /> returned pci_dev and also decrease the reference count for the input<br /> pci_dev @from if it is not NULL.<br /> <br /> If we break for_each_pci_dev() loop with pdev not NULL, we need to call<br /> pci_dev_put() to decrease the reference count. Add the missing<br /> pci_dev_put() after the &amp;#39;out&amp;#39; label. Since pci_dev_put() can handle NULL<br /> input parameter, there is no problem for the &amp;#39;Device not found&amp;#39; branch.<br /> For the normal path, add pci_dev_put() in amd_gpio_exit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: fix using __this_cpu_add in preemptible<br /> <br /> Currently in nf_conntrack_hash_check_insert(), when it fails in<br /> nf_ct_ext_valid_pre/post(), NF_CT_STAT_INC() will be called in the<br /> preemptible context, a call trace can be triggered:<br /> <br /> BUG: using __this_cpu_add() in preemptible [00000000] code: conntrack/1636<br /> caller is nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x33/0x46<br /> check_preemption_disabled+0xc3/0xf0<br /> nf_conntrack_hash_check_insert+0x45/0x430 [nf_conntrack]<br /> ctnetlink_create_conntrack+0x3cd/0x4e0 [nf_conntrack_netlink]<br /> ctnetlink_new_conntrack+0x1c0/0x450 [nf_conntrack_netlink]<br /> nfnetlink_rcv_msg+0x277/0x2f0 [nfnetlink]<br /> netlink_rcv_skb+0x50/0x100<br /> nfnetlink_rcv+0x65/0x144 [nfnetlink]<br /> netlink_unicast+0x1ae/0x290<br /> netlink_sendmsg+0x257/0x4f0<br /> sock_sendmsg+0x5f/0x70<br /> <br /> This patch is to fix it by changing to use NF_CT_STAT_INC_ATOMIC() for<br /> nf_ct_ext_valid_pre/post() check in nf_conntrack_hash_check_insert(),<br /> as well as nf_ct_ext_valid_post() in __nf_conntrack_confirm().<br /> <br /> Note that nf_ct_ext_valid_pre() check in __nf_conntrack_confirm() is<br /> safe to use NF_CT_STAT_INC(), as it&amp;#39;s under local_bh_disable().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: fix memory leak in gpiochip_setup_dev()<br /> <br /> Here is a backtrace report about memory leak detected in<br /> gpiochip_setup_dev():<br /> <br /> unreferenced object 0xffff88810b406400 (size 512):<br /> comm "python3", pid 1682, jiffies 4295346908 (age 24.090s)<br /> backtrace:<br /> kmalloc_trace<br /> device_add device_private_init at drivers/base/core.c:3361<br /> (inlined by) device_add at drivers/base/core.c:3411<br /> cdev_device_add<br /> gpiolib_cdev_register<br /> gpiochip_setup_dev<br /> gpiochip_add_data_with_key<br /> <br /> gcdev_register() &amp; gcdev_unregister() would call device_add() &amp;<br /> device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to<br /> register/unregister device.<br /> <br /> However, if device_add() succeeds, some resource (like<br /> struct device_private allocated by device_private_init())<br /> is not released by device_del().<br /> <br /> Therefore, after device_add() succeeds by gcdev_register(), it<br /> needs to call put_device() to release resource in the error handle<br /> path.<br /> <br /> Here we move forward the register of release function, and let it<br /> release every piece of resource by put_device() instead of kfree().<br /> <br /> While at it, fix another subtle issue, i.e. when gc-&gt;ngpio is equal<br /> to 0, we still call kcalloc() and, in case of further error, kfree()<br /> on the ZERO_PTR pointer, which is not NULL. It&amp;#39;s not a bug per se,<br /> but rather waste of the resources and potentially wrong expectation<br /> about contents of the gdev-&gt;descs variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable_offload: fix using __this_cpu_add in preemptible<br /> <br /> flow_offload_queue_work() can be called in workqueue without<br /> bh disabled, like the call trace showed in my act_ct testing,<br /> calling NF_FLOW_TABLE_STAT_INC() there would cause a call<br /> trace:<br /> <br /> BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u4:0/138560<br /> caller is flow_offload_queue_work+0xec/0x1b0 [nf_flow_table]<br /> Workqueue: act_ct_workqueue tcf_ct_flow_table_cleanup_work [act_ct]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x33/0x46<br /> check_preemption_disabled+0xc3/0xf0<br /> flow_offload_queue_work+0xec/0x1b0 [nf_flow_table]<br /> nf_flow_table_iterate+0x138/0x170 [nf_flow_table]<br /> nf_flow_table_free+0x140/0x1a0 [nf_flow_table]<br /> tcf_ct_flow_table_cleanup_work+0x2f/0x2b0 [act_ct]<br /> process_one_work+0x6a3/0x1030<br /> worker_thread+0x8a/0xdf0<br /> <br /> This patch fixes it by using NF_FLOW_TABLE_STAT_INC_ATOMIC()<br /> instead in flow_offload_queue_work().<br /> <br /> Note that for FLOW_CLS_REPLACE branch in flow_offload_queue_work(),<br /> it may not be called in preemptible path, but it&amp;#39;s good to use<br /> NF_FLOW_TABLE_STAT_INC_ATOMIC() for all cases in<br /> flow_offload_queue_work().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: af_can: fix NULL pointer dereference in can_rcv_filter<br /> <br /> Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer<br /> dereference in can_rx_register()") we need to check for a missing<br /> initialization of ml_priv in the receive path of CAN frames.<br /> <br /> Since commit 4e096a18867a ("net: introduce CAN specific pointer in the<br /> struct net_device") the check for dev-&gt;type to be ARPHRD_CAN is not<br /> sufficient anymore since bonding or tun netdevices claim to be CAN<br /> devices but do not initialize ml_priv accordingly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: fix shift-out-of-bounds in hid_report_raw_event<br /> <br /> Syzbot reported shift-out-of-bounds in hid_report_raw_event.<br /> <br /> microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) &gt;<br /> 32! (swapper/0)<br /> ======================================================================<br /> UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20<br /> shift exponent 127 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> CPU: 0 PID: 0 Comm: swapper/0 Not tainted<br /> 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS<br /> Google 10/26/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106<br /> ubsan_epilogue lib/ubsan.c:151 [inline]<br /> __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322<br /> snto32 drivers/hid/hid-core.c:1323 [inline]<br /> hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]<br /> hid_process_report drivers/hid/hid-core.c:1665 [inline]<br /> hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998<br /> hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066<br /> hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284<br /> __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671<br /> dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988<br /> call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474<br /> expire_timers kernel/time/timer.c:1519 [inline]<br /> __run_timers+0x76a/0x980 kernel/time/timer.c:1790<br /> run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803<br /> __do_softirq+0x277/0x75b kernel/softirq.c:571<br /> __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650<br /> irq_exit_rcu+0x5/0x20 kernel/softirq.c:662<br /> sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107<br /> ======================================================================<br /> <br /> If the size of the integer (unsigned n) is bigger than 32 in snto32(),<br /> shift exponent will be too large for 32-bit type &amp;#39;int&amp;#39;, resulting in a<br /> shift-out-of-bounds bug.<br /> Fix this by adding a check on the size of the integer (unsigned n) in<br /> snto32(). To add support for n greater than 32 bits, set n to 32, if n<br /> is greater than 32.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix array index out of bound error in DCN32 DML<br /> <br /> [Why&amp;How]<br /> LinkCapacitySupport array is indexed with the number of voltage states and<br /> not the number of max DPPs. Fix the error by changing the array<br /> declaration to use the correct (larger) array size of total number of<br /> voltage states.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hisilicon: Fix potential use-after-free in hisi_femac_rx()<br /> <br /> The skb is delivered to napi_gro_receive() which may free it, after<br /> calling this, dereferencing skb may trigger use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: iosm: fix memory leak in ipc_mux_init()<br /> <br /> When failed to alloc ipc_mux-&gt;ul_adb.pp_qlt in ipc_mux_init(), ipc_mux<br /> is not released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ravb: Fix potential use-after-free in ravb_rx_gbeth()<br /> <br /> The skb is delivered to napi_gro_receive() which may free it, after calling this,<br /> dereferencing skb may trigger use-after-free.