Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: Fix array-index-out-of-bounds in diFree

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to truncate preallocated blocks in f2fs_file_open()<br /> <br /> chenyuwen reports a f2fs bug as below:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000011<br /> fscrypt_set_bio_crypt_ctx+0x78/0x1e8<br /> f2fs_grab_read_bio+0x78/0x208<br /> f2fs_submit_page_read+0x44/0x154<br /> f2fs_get_read_data_page+0x288/0x5f4<br /> f2fs_get_lock_data_page+0x60/0x190<br /> truncate_partial_data_page+0x108/0x4fc<br /> f2fs_do_truncate_blocks+0x344/0x5f0<br /> f2fs_truncate_blocks+0x6c/0x134<br /> f2fs_truncate+0xd8/0x200<br /> f2fs_iget+0x20c/0x5ac<br /> do_garbage_collect+0x5d0/0xf6c<br /> f2fs_gc+0x22c/0x6a4<br /> f2fs_disable_checkpoint+0xc8/0x310<br /> f2fs_fill_super+0x14bc/0x1764<br /> mount_bdev+0x1b4/0x21c<br /> f2fs_mount+0x20/0x30<br /> legacy_get_tree+0x50/0xbc<br /> vfs_get_tree+0x5c/0x1b0<br /> do_new_mount+0x298/0x4cc<br /> path_mount+0x33c/0x5fc<br /> __arm64_sys_mount+0xcc/0x15c<br /> invoke_syscall+0x60/0x150<br /> el0_svc_common+0xb8/0xf8<br /> do_el0_svc+0x28/0xa0<br /> el0_svc+0x24/0x84<br /> el0t_64_sync_handler+0x88/0xec<br /> <br /> It is because inode.i_crypt_info is not initialized during below path:<br /> - mount<br /> - f2fs_fill_super<br /> - f2fs_disable_checkpoint<br /> - f2fs_gc<br /> - f2fs_iget<br /> - f2fs_truncate<br /> <br /> So, let&amp;#39;s relocate truncation of preallocated blocks to f2fs_file_open(),<br /> after fscrypt_file_open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_rproc: Skip over memory region when node value is NULL<br /> <br /> In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts<br /> number of phandles. But phandles may be empty. So of_parse_phandle() in<br /> the parsing loop (0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethtool: pse-pd: Fix possible null-deref<br /> <br /> Fix a possible null dereference when a PSE supports both c33 and PoDL, but<br /> only one of the netlink attributes is specified. The c33 or PoDL PSE<br /> capabilities are already validated in the ethnl_set_pse_validate() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix overflow check in adjust_jmp_off()<br /> <br /> adjust_jmp_off() incorrectly used the insn-&gt;imm field for all overflow check,<br /> which is incorrect as that should only be done or the BPF_JMP32 | BPF_JA case,<br /> not the general jump instruction case. Fix it by using insn-&gt;off for overflow<br /> check in the general case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv, bpf: Fix out-of-bounds issue when preparing trampoline image<br /> <br /> We get the size of the trampoline image during the dry run phase and<br /> allocate memory based on that size. The allocated image will then be<br /> populated with instructions during the real patch phase. But after<br /> commit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), the `im`<br /> argument is inconsistent in the dry run and real patch phase. This may<br /> cause emit_imm in RV64 to generate a different number of instructions<br /> when generating the &amp;#39;im&amp;#39; address, potentially causing out-of-bounds<br /> issues. Let&amp;#39;s emit the maximum number of instructions for the "im"<br /> address during dry run to fix this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: wow: fix GTK offload H2C skbuff issue<br /> <br /> We mistakenly put skb too large and that may exceed skb-&gt;end.<br /> Therefore, we fix it.<br /> <br /> skbuff: skb_over_panic: text:ffffffffc09e9a9d len:416 put:204 head:ffff8fba04eca780 data:ffff8fba04eca7e0 tail:0x200 end:0x140 dev:<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:192!<br /> invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 4747 Comm: kworker/u4:44 Tainted: G O 6.6.30-02659-gc18865c4dfbd #1 86547039b47e46935493f615ee31d0b2d711d35e<br /> Hardware name: HP Meep/Meep, BIOS Google_Meep.11297.262.0 03/18/2021<br /> Workqueue: events_unbound async_run_entry_fn<br /> RIP: 0010:skb_panic+0x5d/0x60<br /> Code: c6 63 8b 8f bb 4c 0f 45 f6 48 c7 c7 4d 89 8b bb 48 89 ce 44 89 d1 41 56 53 41 53 ff b0 c8 00 00 00 e8 27 5f 23 00 48 83 c4 20 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44<br /> RSP: 0018:ffffaa700144bad0 EFLAGS: 00010282<br /> RAX: 0000000000000089 RBX: 0000000000000140 RCX: 14432c5aad26c900<br /> RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 0000000000000001<br /> RBP: ffffaa700144bae0 R08: 0000000000000000 R09: ffffaa700144b920<br /> R10: 00000000ffffdfff R11: ffffffffbc28fbc0 R12: ffff8fba4e57a010<br /> R13: 0000000000000000 R14: ffffffffbb8f8b63 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8fba7bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007999c4ad1000 CR3: 000000015503a000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> ? __die_body+0x1f/0x70<br /> ? die+0x3d/0x60<br /> ? do_trap+0xa4/0x110<br /> ? skb_panic+0x5d/0x60<br /> ? do_error_trap+0x6d/0x90<br /> ? skb_panic+0x5d/0x60<br /> ? handle_invalid_op+0x30/0x40<br /> ? skb_panic+0x5d/0x60<br /> ? exc_invalid_op+0x3c/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? skb_panic+0x5d/0x60<br /> skb_put+0x49/0x50<br /> rtw89_fw_h2c_wow_gtk_ofld+0xbd/0x220 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]<br /> rtw89_wow_resume+0x31f/0x540 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]<br /> rtw89_ops_resume+0x2b/0xa0 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]<br /> ieee80211_reconfig+0x84/0x13e0 [mac80211 818a894e3b77da6298269c59ed7cdff065a4ed52]<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]<br /> ? dev_printk_emit+0x51/0x70<br /> ? _dev_info+0x6e/0x90<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]<br /> wiphy_resume+0x89/0x180 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]<br /> dpm_run_callback+0x3c/0x140<br /> device_resume+0x1f9/0x3c0<br /> ? __pfx_dpm_watchdog_handler+0x10/0x10<br /> async_resume+0x1d/0x30<br /> async_run_entry_fn+0x29/0xd0<br /> process_scheduled_works+0x1d8/0x3d0<br /> worker_thread+0x1fc/0x2f0<br /> kthread+0xed/0x110<br /> ? __pfx_worker_thread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x38/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> Modules linked in: ccm 8021q r8153_ecm cdc_ether usbnet r8152 mii dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc uinput rfcomm cmac algif_hash rtw89_8922ae(O) algif_skcipher rtw89_8922a(O) af_alg rtw89_pci(O) rtw89_core(O) btusb(O) snd_soc_sst_bxt_da7219_max98357a btbcm(O) snd_soc_hdac_hdmi btintel(O) snd_soc_intel_hda_dsp_common snd_sof_probes btrtl(O) btmtk(O) snd_hda_codec_hdmi snd_soc_dmic uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_sof_pci_intel_apl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda soundwire_intel soundwire_generic_allocation snd_sof_intel_hda_mlink soundwire_cadence snd_sof_pci snd_sof_xtensa_dsp mac80211 snd_soc_acpi_intel_match snd_soc_acpi snd_sof snd_sof_utils soundwire_bus snd_soc_max98357a snd_soc_avs snd_soc_hda_codec snd_hda_ext_core snd_intel_dspcfg snd_intel_sdw_acpi snd_soc_da7219 snd_hda_codec snd_hwdep snd_hda_core veth ip6table_nat xt_MASQUERADE xt_cgroup fuse bluetooth ecdh_generic<br /> cfg80211 ecc<br /> gsmi: Log Shutdown <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix bogus checksum computation in udf_rename()<br /> <br /> Syzbot reports uninitialized memory access in udf_rename() when updating<br /> checksum of &amp;#39;..&amp;#39; directory entry of a moved directory. This is indeed<br /> true as we pass on-stack diriter.fi to the udf_update_tag() and because<br /> that has only struct fileIdentDesc included in it and not the impUse or<br /> name fields, the checksumming function is going to checksum random stack<br /> contents beyond the end of the structure. This is actually harmless<br /> because the following udf_fiiter_write_fi() will recompute the checksum<br /> from on-disk buffers where everything is properly included. So all that<br /> is needed is just removing the bogus calculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix invalid memory access while processing fragmented packets<br /> <br /> The monitor ring and the reo reinject ring share the same ring mask index.<br /> When the driver receives an interrupt for the reo reinject ring, the<br /> monitor ring is also processed, leading to invalid memory access. Since<br /> monitor support is not yet enabled in ath12k, the ring mask for the monitor<br /> ring should be removed.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG<br /> <br /> When BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls<br /> __bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them<br /> the struct bpf_tramp_image *im pointer as an argument in R0.<br /> <br /> The trampoline generation code uses emit_addr_mov_i64() to emit<br /> instructions for moving the bpf_tramp_image address into R0, but<br /> emit_addr_mov_i64() assumes the address to be in the vmalloc() space<br /> and uses only 48 bits. Because bpf_tramp_image is allocated using<br /> kzalloc(), its address can use more than 48-bits, in this case the<br /> trampoline will pass an invalid address to __bpf_tramp_enter/exit()<br /> causing a kernel crash.<br /> <br /> Fix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64()<br /> as it can work with addresses that are greater than 48-bits.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l: async: Fix NULL pointer dereference in adding ancillary links<br /> <br /> In v4l2_async_create_ancillary_links(), ancillary links are created for<br /> lens and flash sub-devices. These are sub-device to sub-device links and<br /> if the async notifier is related to a V4L2 device, the source sub-device<br /> of the ancillary link is NULL, leading to a NULL pointer dereference.<br /> Check the notifier&amp;#39;s sd field is non-NULL in<br /> v4l2_async_create_ancillary_links().<br /> <br /> [Sakari Ailus: Reword the subject and commit messages slightly.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp: fix invalid wait context of page_pool_destroy()<br /> <br /> If the driver uses a page pool, it creates a page pool with<br /> page_pool_create().<br /> The reference count of page pool is 1 as default.<br /> A page pool will be destroyed only when a reference count reaches 0.<br /> page_pool_destroy() is used to destroy page pool, it decreases a<br /> reference count.<br /> When a page pool is destroyed, -&gt;disconnect() is called, which is<br /> mem_allocator_disconnect().<br /> This function internally acquires mutex_lock().<br /> <br /> If the driver uses XDP, it registers a memory model with<br /> xdp_rxq_info_reg_mem_model().<br /> The xdp_rxq_info_reg_mem_model() internally increases a page pool<br /> reference count if a memory model is a page pool.<br /> Now the reference count is 2.<br /> <br /> To destroy a page pool, the driver should call both page_pool_destroy()<br /> and xdp_unreg_mem_model().<br /> The xdp_unreg_mem_model() internally calls page_pool_destroy().<br /> Only page_pool_destroy() decreases a reference count.<br /> <br /> If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we<br /> will face an invalid wait context warning.<br /> Because xdp_unreg_mem_model() calls page_pool_destroy() with<br /> rcu_read_lock().<br /> The page_pool_destroy() internally acquires mutex_lock().<br /> <br /> Splat looks like:<br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.10.0-rc6+ #4 Tainted: G W<br /> -----------------------------<br /> ethtool/1806 is trying to lock:<br /> ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 3 locks held by ethtool/1806:<br /> stack backtrace:<br /> CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed<br /> Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7e/0xc0<br /> __lock_acquire+0x1681/0x4de0<br /> ? _printk+0x64/0xe0<br /> ? __pfx_mark_lock.part.0+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> lock_acquire+0x1b3/0x580<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __wake_up_klogd.part.0+0x16/0xc0<br /> ? __pfx_lock_acquire+0x10/0x10<br /> ? dump_stack_lvl+0x91/0xc0<br /> __mutex_lock+0x15c/0x1690<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_prb_read_valid+0x10/0x10<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_llist_add_batch+0x10/0x10<br /> ? console_unlock+0x193/0x1b0<br /> ? lockdep_hardirqs_on+0xbe/0x140<br /> ? __pfx___mutex_lock+0x10/0x10<br /> ? tick_nohz_tick_stopped+0x16/0x90<br /> ? __irq_work_queue_local+0x1e5/0x330<br /> ? irq_work_queue+0x39/0x50<br /> ? __wake_up_klogd.part.0+0x79/0xc0<br /> ? mem_allocator_disconnect+0x73/0x150<br /> mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_mem_allocator_disconnect+0x10/0x10<br /> ? mark_held_locks+0xa5/0xf0<br /> ? rcu_is_watching+0x11/0xb0<br /> page_pool_release+0x36e/0x6d0<br /> page_pool_destroy+0xd7/0x440<br /> xdp_unreg_mem_model+0x1a7/0x2a0<br /> ? __pfx_xdp_unreg_mem_model+0x10/0x10<br /> ? kfree+0x125/0x370<br /> ? bnxt_free_ring.isra.0+0x2eb/0x500<br /> ? bnxt_free_mem+0x5ac/0x2500<br /> xdp_rxq_info_unreg+0x4a/0xd0<br /> bnxt_free_mem+0x1356/0x2500<br /> bnxt_close_nic+0xf0/0x3b0<br /> ? __pfx_bnxt_close_nic+0x10/0x10<br /> ? ethnl_parse_bit+0x2c6/0x6d0<br /> ? __pfx___nla_validate_parse+0x10/0x10<br /> ? __pfx_ethnl_parse_bit+0x10/0x10<br /> bnxt_set_features+0x2a8/0x3e0<br /> __netdev_update_features+0x4dc/0x1370<br /> ? ethnl_parse_bitset+0x4ff/0x750<br /> ? __pfx_ethnl_parse_bitset+0x10/0x10<br /> ? __pfx___netdev_update_features+0x10/0x10<br /> ? mark_held_locks+0xa5/0xf0<br /> ? _raw_spin_unlock_irqrestore+0x42/0x70<br /> ? __pm_runtime_resume+0x7d/0x110<br /> ethnl_set_features+0x32d/0xa20<br /> <br /> To fix this problem, it uses rhashtable_lookup_fast() instead of<br /> rhashtable_lookup() with rcu_read_lock().<br /> Using xa without rcu_read_lock() here is safe.<br /> xa is freed by __xdp_mem_allocator_rcu_free() and this is called by<br /> call_rcu() of mem_xa_remove().<br /> The mem_xa_remove() is called by page_pool_destroy() if a reference<br /> count reaches 0.<br /> The xa is already protected by the reference count mechanism well in the<br /> control plane.<br /> So removing rcu_read_lock() for page_pool_destroy() is safe.