Vulnerabilities

Out-of-bounds vulnerability due to improper memory release during image rendering in Generic PCL6 V4 Printer Driver / Generic UFR II V4 Printer Driver / Generic LIPSLX V4 Printer Driver.

Out-of-bounds vulnerability in slope processing during curve rendering in Generic PCL6 V4 Printer Driver / Generic UFR II V4 Printer Driver / Generic LIPSLX V4 Printer Driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred<br /> <br /> Similar to the handling of play_deferred in commit 19cfe912c37b<br /> ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought<br /> a patch might be needed here as well.<br /> <br /> Currently usb_submit_urb is called directly to submit deferred tx<br /> urbs after unanchor them.<br /> <br /> So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb<br /> and cause memory leak.<br /> <br /> Put those urbs in tx_anchor to avoid the leak, and also fix the error<br /> handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo()<br /> <br /> In an unlikely (and probably wrong?) case that the &amp;#39;ppi&amp;#39; parameter of<br /> ata_host_alloc_pinfo() points to an array starting with a NULL pointer,<br /> there&amp;#39;s going to be a kernel oops as the &amp;#39;pi&amp;#39; local variable won&amp;#39;t get<br /> reassigned from the initial value of NULL. Initialize &amp;#39;pi&amp;#39; instead to<br /> &amp;#39;&amp;ata_dummy_port_info&amp;#39; to fix the possible kernel oops for good...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: goldfish: Fix free_irq() on remove<br /> <br /> Pass the correct dev_id to free_irq() to fix this splat when the driver<br /> is unbound:<br /> <br /> WARNING: CPU: 0 PID: 30 at kernel/irq/manage.c:1895 free_irq<br /> Trying to free already-free IRQ 65<br /> Call Trace:<br /> warn_slowpath_fmt<br /> free_irq<br /> goldfish_tty_remove<br /> platform_remove<br /> device_remove<br /> device_release_driver_internal<br /> device_driver_detach<br /> unbind_store<br /> drv_attr_store<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix call trace in setup_tx_descriptors<br /> <br /> After PF reset and ethtool -t there was call trace in dmesg<br /> sometimes leading to panic. When there was some time, around 5<br /> seconds, between reset and test there were no errors.<br /> <br /> Problem was that pf reset calls i40e_vsi_close in prep_for_reset<br /> and ethtool -t calls i40e_vsi_close in diag_test. If there was not<br /> enough time between those commands the second i40e_vsi_close starts<br /> before previous i40e_vsi_close was done which leads to crash.<br /> <br /> Add check to diag_test if pf is in reset and don&amp;#39;t start offline<br /> tests if it is true.<br /> Add netif_info("testing failed") into unhappy path of i40e_diag_test()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource: hyper-v: unexport __init-annotated hv_init_clocksource()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the only in-tree call-site,<br /> arch/x86/kernel/cpu/mshyperv.c is never compiled as modular.<br /> (CONFIG_HYPERVISOR_GUEST is boolean)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg<br /> <br /> When len &gt;= INT_MAX - transhdrlen, ulen = len + transhdrlen will be<br /> overflow. To fix, we can follow what udpv6 does and subtract the<br /> transhdrlen from the max.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix signed integer overflow in __ip6_append_data<br /> <br /> Resurrect ubsan overflow checks and ubsan report this warning,<br /> fix it by change the variable [length] type to size_t.<br /> <br /> UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:19<br /> 2147479552 + 8567 cannot be represented in type &amp;#39;int&amp;#39;<br /> CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace+0x214/0x230<br /> show_stack+0x30/0x78<br /> dump_stack_lvl+0xf8/0x118<br /> dump_stack+0x18/0x30<br /> ubsan_epilogue+0x18/0x60<br /> handle_overflow+0xd0/0xf0<br /> __ubsan_handle_add_overflow+0x34/0x44<br /> __ip6_append_data.isra.48+0x1598/0x1688<br /> ip6_append_data+0x128/0x260<br /> udpv6_sendmsg+0x680/0xdd0<br /> inet6_sendmsg+0x54/0x90<br /> sock_sendmsg+0x70/0x88<br /> ____sys_sendmsg+0xe8/0x368<br /> ___sys_sendmsg+0x98/0xe0<br /> __sys_sendmmsg+0xf4/0x3b8<br /> __arm64_sys_sendmmsg+0x34/0x48<br /> invoke_syscall+0x64/0x160<br /> el0_svc_common.constprop.4+0x124/0x300<br /> do_el0_svc+0x44/0xc8<br /> el0_svc+0x3c/0x1e8<br /> el0t_64_sync_handler+0x88/0xb0<br /> el0t_64_sync+0x16c/0x170<br /> <br /> Changes since v1:<br /> -Change the variable [length] type to unsigned, as Eric Dumazet suggested.<br /> Changes since v2:<br /> -Don&amp;#39;t change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.<br /> Changes since v3:<br /> -Don&amp;#39;t change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, as<br /> Jakub Kicinski suggested.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: Fix memory leak in dwc2_hcd_init<br /> <br /> usb_create_hcd will alloc memory for hcd, and we should<br /> call usb_put_hcd to free it when platform_get_resource()<br /> fails to prevent memory leak.<br /> goto error2 label instead error1 to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/realtek-rtl: Fix refcount leak in map_interrupts<br /> <br /> of_find_node_by_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> This function doesn&amp;#39;t call of_node_put() in error path.<br /> Call of_node_put() directly after of_property_read_u32() to cover<br /> both normal path and error path.