Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath9k_htc: fix potential out of bounds access with invalid rxstatus-&gt;rs_keyix<br /> <br /> The "rxstatus-&gt;rs_keyix" eventually gets passed to test_bit() so we need to<br /> ensure that it is within the bitmap.<br /> <br /> drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept()<br /> error: passing untrusted data &amp;#39;rx_stats-&gt;rs_keyix&amp;#39; to &amp;#39;test_bit()&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Inhibit aborts if external loopback plug is inserted<br /> <br /> After running a short external loopback test, when the external loopback is<br /> removed and a normal cable inserted that is directly connected to a target<br /> device, the system oops in the llpfc_set_rrq_active() routine.<br /> <br /> When the loopback was inserted an FLOGI was transmit. As we&amp;#39;re looped back,<br /> we receive the FLOGI request. The FLOGI is ABTS&amp;#39;d as we recognize the same<br /> wppn thus understand it&amp;#39;s a loopback. However, as the ABTS sends address<br /> information the port is not set to (fffffe), the ABTS is dropped on the<br /> wire. A short 1 frame loopback test is run and completes before the ABTS<br /> times out. The looback is unplugged and the new cable plugged in, and the<br /> an FLOGI to the new device occurs and completes. Due to a mixup in ref<br /> counting the completion of the new FLOGI releases the fabric ndlp. Then the<br /> original ABTS completes and references the released ndlp generating the<br /> oops.<br /> <br /> Correct by no-op&amp;#39;ing the ABTS when in loopback mode (it will be dropped<br /> anyway). Added a flag to track the mode to recognize when it should be<br /> no-op&amp;#39;d.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: NULL out the dev-&gt;rfkill to prevent UAF<br /> <br /> Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")<br /> assumes the device_is_registered() in function nfc_dev_up() will help<br /> to check when the rfkill is unregistered. However, this check only<br /> take effect when device_del(&amp;dev-&gt;dev) is done in nfc_unregister_device().<br /> Hence, the rfkill object is still possible be dereferenced.<br /> <br /> The crash trace in latest kernel (5.18-rc2):<br /> <br /> [ 68.760105] ==================================================================<br /> [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750<br /> [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313<br /> [ 68.760756]<br /> [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4<br /> [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 68.760756] Call Trace:<br /> [ 68.760756] <br /> [ 68.760756] dump_stack_lvl+0x57/0x7d<br /> [ 68.760756] print_report.cold+0x5e/0x5db<br /> [ 68.760756] ? __lock_acquire+0x3ec1/0x6750<br /> [ 68.760756] kasan_report+0xbe/0x1c0<br /> [ 68.760756] ? __lock_acquire+0x3ec1/0x6750<br /> [ 68.760756] __lock_acquire+0x3ec1/0x6750<br /> [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410<br /> [ 68.760756] ? register_lock_class+0x18d0/0x18d0<br /> [ 68.760756] lock_acquire+0x1ac/0x4f0<br /> [ 68.760756] ? rfkill_blocked+0xe/0x60<br /> [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410<br /> [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0<br /> [ 68.760756] ? nla_get_range_signed+0x540/0x540<br /> [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50<br /> [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50<br /> [ 68.760756] ? rfkill_blocked+0xe/0x60<br /> [ 68.760756] rfkill_blocked+0xe/0x60<br /> [ 68.760756] nfc_dev_up+0x84/0x260<br /> [ 68.760756] nfc_genl_dev_up+0x90/0xe0<br /> [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0<br /> [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230<br /> [ 68.760756] ? security_capable+0x51/0x90<br /> [ 68.760756] genl_rcv_msg+0x280/0x500<br /> [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0<br /> [ 68.760756] ? lock_acquire+0x1ac/0x4f0<br /> [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0<br /> [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410<br /> [ 68.760756] netlink_rcv_skb+0x11b/0x340<br /> [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0<br /> [ 68.760756] ? netlink_ack+0x9c0/0x9c0<br /> [ 68.760756] ? netlink_deliver_tap+0x136/0xb00<br /> [ 68.760756] genl_rcv+0x1f/0x30<br /> [ 68.760756] netlink_unicast+0x430/0x710<br /> [ 68.760756] ? memset+0x20/0x40<br /> [ 68.760756] ? netlink_attachskb+0x740/0x740<br /> [ 68.760756] ? __build_skb_around+0x1f4/0x2a0<br /> [ 68.760756] netlink_sendmsg+0x75d/0xc00<br /> [ 68.760756] ? netlink_unicast+0x710/0x710<br /> [ 68.760756] ? netlink_unicast+0x710/0x710<br /> [ 68.760756] sock_sendmsg+0xdf/0x110<br /> [ 68.760756] __sys_sendto+0x19e/0x270<br /> [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0<br /> [ 68.760756] ? fd_install+0x178/0x4c0<br /> [ 68.760756] ? fd_install+0x195/0x4c0<br /> [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0<br /> [ 68.760756] __x64_sys_sendto+0xd8/0x1b0<br /> [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130<br /> [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50<br /> [ 68.760756] do_syscall_64+0x3b/0x90<br /> [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 68.760756] RIP: 0033:0x7f67fb50e6b3<br /> ...<br /> [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c<br /> [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3<br /> [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003<br /> [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c<br /> [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e<br /> [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003<br /> <br /> [ 68.760756] <br /> [ 68.760756]<br /> [ 68.760756] Allocated by task 279:<br /> [ 68.760756] kasan_save_stack+0x1e/0x40<br /> [<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Add vblank register/unregister callback functions<br /> <br /> We encountered a kernel panic issue that callback data will be NULL when<br /> it&amp;#39;s using in ovl irq handler. There is a timing issue between<br /> mtk_disp_ovl_irq_handler() and mtk_ovl_disable_vblank().<br /> <br /> To resolve this issue, we use the flow to register/unregister vblank cb:<br /> - Register callback function and callback data when crtc creates.<br /> - Unregister callback function and callback data when crtc destroies.<br /> <br /> With this solution, we can assure callback data will not be NULL when<br /> vblank is disable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: da9121: Fix uninit-value in da9121_assign_chip_model()<br /> <br /> KASAN report slab-out-of-bounds in __regmap_init as follows:<br /> <br /> BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841<br /> Read of size 1 at addr ffff88803678cdf1 by task xrun/9137<br /> <br /> CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88<br /> print_report.cold+0xcd/0x69b mm/kasan/report.c:313<br /> kasan_report+0x8e/0xc0 mm/kasan/report.c:491<br /> __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841<br /> __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266<br /> __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394<br /> da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039<br /> i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563<br /> <br /> This happend when da9121 device is probe by da9121_i2c_id, but with<br /> invalid dts. Thus, chip-&gt;subvariant_id is set to -EINVAL, and later<br /> da9121_assign_chip_model() will access &amp;#39;regmap&amp;#39; without init it.<br /> <br /> Fix it by return -EINVAL from da9121_assign_chip_model() if<br /> &amp;#39;chip-&gt;subvariant_id&amp;#39; is invalid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: elan: Fix potential double free in elan_input_configured<br /> <br /> &amp;#39;input&amp;#39; is a managed resource allocated with devm_input_allocate_device(),<br /> so there is no need to call input_free_device() explicitly or<br /> there will be a double free.<br /> <br /> According to the doc of devm_input_allocate_device():<br /> * Managed input devices do not need to be explicitly unregistered or<br /> * freed as it will be done automatically when owner device unbinds from<br /> * its driver (or binding fails).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume<br /> <br /> BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3<br /> <br /> Call trace:<br /> dpu_vbif_init_memtypes+0x40/0xb8<br /> dpu_runtime_resume+0xcc/0x1c0<br /> pm_generic_runtime_resume+0x30/0x44<br /> __genpd_runtime_resume+0x68/0x7c<br /> genpd_runtime_resume+0x134/0x258<br /> __rpm_callback+0x98/0x138<br /> rpm_callback+0x30/0x88<br /> rpm_resume+0x36c/0x49c<br /> __pm_runtime_resume+0x80/0xb0<br /> dpu_core_irq_uninstall+0x30/0xb0<br /> dpu_irq_uninstall+0x18/0x24<br /> msm_drm_uninit+0xd8/0x16c<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/483255/<br /> [DB: fixed Fixes tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected<br /> <br /> mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring<br /> the modeset lock, but currently mdp5_pipe_release doesn&amp;#39;t check for if<br /> an error is returned. Because of this, there is a possibility of<br /> mdp5_pipe_release hitting a NULL dereference error.<br /> <br /> To avoid this, let&amp;#39;s have mdp5_pipe_release check if<br /> mdp5_get_global_state returns an error and propogate that error.<br /> <br /> Changes since v1:<br /> - Separated declaration and initialization of *new_state to avoid<br /> compiler warning<br /> - Fixed some spelling mistakes in commit message<br /> <br /> Changes since v2:<br /> - Return 0 in case where hwpipe is NULL as this is considered normal<br /> behavior<br /> - Added 2nd patch in series to fix a similar NULL dereference issue in<br /> mdp5_mixer_release<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/485179/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()<br /> <br /> It will cause null-ptr-deref in resource_size(), if platform_get_resource()<br /> returns NULL, move calling resource_size() after devm_ioremap_resource() that<br /> will check &amp;#39;res&amp;#39; to avoid null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags<br /> <br /> In nvme_alloc_admin_tags, the admin_q can be set to an error (typically<br /> -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which<br /> is checked immediately after the call. However, when we return the error<br /> message up the stack, to nvme_reset_work the error takes us to<br /> nvme_remove_dead_ctrl()<br /> nvme_dev_disable()<br /> nvme_suspend_queue(&amp;dev-&gt;queues[0]).<br /> <br /> Here, we only check that the admin_q is non-NULL, rather than not<br /> an error or NULL, and begin quiescing a queue that never existed, leading<br /> to bad / NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: rt5645: Fix errorenous cleanup order<br /> <br /> There is a logic error when removing rt5645 device as the function<br /> rt5645_i2c_remove() first cancel the &amp;rt5645-&gt;jack_detect_work and<br /> delete the &amp;rt5645-&gt;btn_check_timer latter. However, since the timer<br /> handler rt5645_btn_check_callback() will re-queue the jack_detect_work,<br /> this cleanup order is buggy.<br /> <br /> That is, once the del_timer_sync in rt5645_i2c_remove is concurrently<br /> run with the rt5645_btn_check_callback, the canceled jack_detect_work<br /> will be rescheduled again, leading to possible use-after-free.<br /> <br /> This patch fix the issue by placing the del_timer_sync function before<br /> the cancel_delayed_work_sync.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.