Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen-netfront: Fix NULL sring after live migration<br /> <br /> A NAPI is setup for each network sring to poll data to kernel<br /> The sring with source host is destroyed before live migration and<br /> new sring with target host is setup after live migration.<br /> The NAPI for the old sring is not deleted until setup new sring<br /> with target host after migration. With busy_poll/busy_read enabled,<br /> the NAPI can be polled before got deleted when resume VM.<br /> <br /> BUG: unable to handle kernel NULL pointer dereference at<br /> 0000000000000008<br /> IP: xennet_poll+0xae/0xd20<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> Call Trace:<br /> finish_task_switch+0x71/0x230<br /> timerqueue_del+0x1d/0x40<br /> hrtimer_try_to_cancel+0xb5/0x110<br /> xennet_alloc_rx_buffers+0x2a0/0x2a0<br /> napi_busy_loop+0xdb/0x270<br /> sock_poll+0x87/0x90<br /> do_sys_poll+0x26f/0x580<br /> tracing_map_insert+0x1d4/0x2f0<br /> event_hist_trigger+0x14a/0x260<br /> <br /> finish_task_switch+0x71/0x230<br /> __schedule+0x256/0x890<br /> recalc_sigpending+0x1b/0x50<br /> xen_sched_clock+0x15/0x20<br /> __rb_reserve_next+0x12d/0x140<br /> ring_buffer_lock_reserve+0x123/0x3d0<br /> event_triggers_call+0x87/0xb0<br /> trace_event_buffer_commit+0x1c4/0x210<br /> xen_clocksource_get_cycles+0x15/0x20<br /> ktime_get_ts64+0x51/0xf0<br /> SyS_ppoll+0x160/0x1a0<br /> SyS_ppoll+0x160/0x1a0<br /> do_syscall_64+0x73/0x130<br /> entry_SYSCALL_64_after_hwframe+0x41/0xa6<br /> ...<br /> RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900<br /> CR2: 0000000000000008<br /> ---[ end trace f8601785b354351c ]---<br /> <br /> xen frontend should remove the NAPIs for the old srings before live<br /> migration as the bond srings are destroyed<br /> <br /> There is a tiny window between the srings are set to NULL and<br /> the NAPIs are disabled, It is safe as the NAPI threads are still<br /> frozen at that time

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Get user_ns from in_skb in unix_diag_get_exact().<br /> <br /> Wei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed<br /> the root cause: in unix_diag_get_exact(), the newly allocated skb does not<br /> have sk. [2]<br /> <br /> We must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to<br /> sk_diag_fill().<br /> <br /> [0]:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000270<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP<br /> CPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:sk_user_ns include/net/sock.h:920 [inline]<br /> RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]<br /> RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170<br /> Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8<br /> 54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd 8b<br /> 9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d<br /> RSP: 0018:ffffc90000d67968 EFLAGS: 00010246<br /> RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d<br /> RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270<br /> RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000<br /> R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800<br /> R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940<br /> FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> unix_diag_get_exact net/unix/diag.c:285 [inline]<br /> unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317<br /> __sock_diag_cmd net/core/sock_diag.c:235 [inline]<br /> sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266<br /> netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564<br /> sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]<br /> netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356<br /> netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0x38f/0x500 net/socket.c:2476<br /> ___sys_sendmsg net/socket.c:2530 [inline]<br /> __sys_sendmsg+0x197/0x230 net/socket.c:2559<br /> __do_sys_sendmsg net/socket.c:2568 [inline]<br /> __se_sys_sendmsg net/socket.c:2566 [inline]<br /> __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x4697f9<br /> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48<br /> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d<br /> 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9<br /> RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003<br /> RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80<br /> R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0<br /> <br /> Modules linked in:<br /> CR2: 0000000000000270<br /> <br /> [1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/<br /> [2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/

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.