Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid out-of-boundary access in devs.path<br /> <br /> - touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123<br /> - truncate -s $((1024*1024*1024)) \<br /> /mnt/f2fs/012345678901234567890123456789012345678901234567890123<br /> - touch /mnt/f2fs/file<br /> - truncate -s $((1024*1024*1024)) /mnt/f2fs/file<br /> - mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \<br /> -c /mnt/f2fs/file<br /> - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \<br /> /mnt/f2fs/loop<br /> <br /> [16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01, 511, 0 - 3ffff<br /> [16937.192268] F2FS-fs (loop0): Failed to find devices<br /> <br /> If device path length equals to MAX_PATH_LEN, sbi-&gt;devs.path[] may<br /> not end up w/ null character due to path array is fully filled, So<br /> accidently, fields locate after path[] may be treated as part of<br /> device path, result in parsing wrong device path.<br /> <br /> struct f2fs_dev_info {<br /> ...<br /> char path[MAX_PATH_LEN];<br /> ...<br /> };<br /> <br /> Let&amp;#39;s add one byte space for sbi-&gt;devs.path[] to store null<br /> character of device path string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al<br /> <br /> Check pde-&gt;proc_ops-&gt;proc_lseek directly may cause UAF in rmmod scenario. <br /> It&amp;#39;s a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in<br /> proc_get_inode()"). Followed by AI Viro&amp;#39;s suggestion, fix it in same<br /> manner.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()<br /> <br /> Preserve the error code if iwl_setup_deferred_work() fails. The current<br /> code returns ERR_PTR(0) (which is NULL) on this path. I believe the<br /> missing error code potentially leads to a use after free involving<br /> debugfs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: mcc: prevent shift wrapping in rtw89_core_mlsr_switch()<br /> <br /> The "link_id" value comes from the user via debugfs. If it&amp;#39;s larger<br /> than BITS_PER_LONG then that would result in shift wrapping and<br /> potentially an out of bounds access later. In fact, we can limit it<br /> to IEEE80211_MLD_MAX_NUM_LINKS (15).<br /> <br /> Fortunately, only root can write to debugfs files so the security<br /> impact is minimal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails<br /> <br /> Have nvmet_req_init() and req-&gt;execute() complete failed commands.<br /> <br /> Description of the problem:<br /> nvmet_req_init() calls __nvmet_req_complete() internally upon failure,<br /> e.g., unsupported opcode, which calls the "queue_response" callback,<br /> this results in nvmet_pci_epf_queue_response() being called, which will<br /> call nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir is<br /> different from DMA_TO_DEVICE. This results in a double completion as<br /> nvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod()<br /> when nvmet_req_init() fails.<br /> <br /> Steps to reproduce:<br /> On the host send a command with an unsupported opcode with nvme-cli,<br /> For example the admin command "security receive"<br /> $ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096<br /> <br /> This triggers a double completion as nvmet_req_init() fails and<br /> nvmet_pci_epf_queue_response() is called, here iod-&gt;dma_dir is still<br /> in the default state of "DMA_NONE" as set by default in<br /> nvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called.<br /> Because nvmet_req_init() failed nvmet_pci_epf_complete_iod() is also<br /> called in nvmet_pci_epf_exec_iod_work() leading to a double completion.<br /> This not only sends two completions to the host but also corrupts the<br /> state of the PCI NVMe target leading to kernel oops.<br /> <br /> This patch lets nvmet_req_init() and req-&gt;execute() complete all failed<br /> commands, and removes the double completion case in<br /> nvmet_pci_epf_exec_iod_work() therefore fixing the edge cases where<br /> double completions occurred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: sar: drop lockdep assertion in rtw89_set_sar_from_acpi<br /> <br /> The following assertion is triggered on the rtw89 driver startup. It<br /> looks meaningless to hold wiphy lock on the early init stage so drop the<br /> assertion.<br /> <br /> WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]<br /> CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy)<br /> Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024<br /> RIP: 0010:rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]<br /> Call Trace:<br /> <br /> rtw89_sar_init+0x68/0x2c0 [rtw89_core]<br /> rtw89_core_init+0x188e/0x1e50 [rtw89_core]<br /> rtw89_pci_probe+0x530/0xb50 [rtw89_pci]<br /> local_pci_probe+0xd9/0x190<br /> pci_call_probe+0x183/0x540<br /> pci_device_probe+0x171/0x2c0<br /> really_probe+0x1e1/0x890<br /> __driver_probe_device+0x18c/0x390<br /> driver_probe_device+0x4a/0x120<br /> __driver_attach+0x1a0/0x530<br /> bus_for_each_dev+0x10b/0x190<br /> bus_add_driver+0x2eb/0x540<br /> driver_register+0x1a3/0x3a0<br /> do_one_initcall+0xd5/0x450<br /> do_init_module+0x2cc/0x8f0<br /> init_module_from_file+0xe1/0x150<br /> idempotent_init_module+0x226/0x760<br /> __x64_sys_finit_module+0xcd/0x150<br /> do_syscall_64+0x94/0x380<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: stm32: Check for cfg availability in stm32_spi_probe<br /> <br /> The stm32_spi_probe function now includes a check to ensure that the<br /> pointer returned by of_device_get_match_data is not NULL before<br /> accessing its members. This resolves a warning where a potential NULL<br /> pointer dereference could occur when accessing cfg-&gt;has_device_mode.<br /> <br /> Before accessing the &amp;#39;has_device_mode&amp;#39; member, we verify that &amp;#39;cfg&amp;#39; is<br /> not NULL. If &amp;#39;cfg&amp;#39; is NULL, an error message is logged.<br /> <br /> This change ensures that the driver does not attempt to access<br /> configuration data if it is not available, thus preventing a potential<br /> system crash due to a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight<br /> <br /> An infinite loop has been created by the Coresight devices. When only a<br /> source device is enabled, the coresight_find_activated_sysfs_sink function<br /> is recursively invoked in an attempt to locate an active sink device,<br /> ultimately leading to a stack overflow and system crash. Therefore, disable<br /> the replicator1 to break the infinite loop and prevent a potential stack<br /> overflow.<br /> <br /> replicator1_out -&gt; funnel_swao_in6 -&gt; tmc_etf_swao_in -&gt; tmc_etf_swao_out<br /> | |<br /> replicator1_in replicator_swao_in<br /> | |<br /> replicator0_out1 replicator_swao_out0<br /> | |<br /> replicator0_in funnel_in1_in3<br /> | |<br /> tmc_etf_out

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: remove mutex_lock check in hfsplus_free_extents<br /> <br /> Syzbot reported an issue in hfsplus filesystem:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346<br /> hfsplus_free_extents+0x700/0xad0<br /> Call Trace:<br /> <br /> hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606<br /> hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56<br /> cont_expand_zero fs/buffer.c:2383 [inline]<br /> cont_write_begin+0x2cf/0x860 fs/buffer.c:2446<br /> hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52<br /> generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347<br /> hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263<br /> notify_change+0xe38/0x10f0 fs/attr.c:420<br /> do_truncate+0x1fb/0x2e0 fs/open.c:65<br /> do_sys_ftruncate+0x2eb/0x380 fs/open.c:193<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock<br /> on file truncation") unlock extree before hfsplus_free_extents(),<br /> and add check wheather extree is locked in hfsplus_free_extents().<br /> <br /> However, when operations such as hfsplus_file_release,<br /> hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed<br /> concurrently in different files, it is very likely to trigger the<br /> WARN_ON, which will lead syzbot and xfstest to consider it as an<br /> abnormality.<br /> <br /> The comment above this warning also describes one of the easy<br /> triggering situations, which can easily trigger and cause<br /> xfstest&amp;syzbot to report errors.<br /> <br /> [task A] [task B]<br /> -&gt;hfsplus_file_release<br /> -&gt;hfsplus_file_truncate<br /> -&gt;hfs_find_init<br /> -&gt;mutex_lock<br /> -&gt;mutex_unlock<br /> -&gt;hfsplus_write_begin<br /> -&gt;hfsplus_get_block<br /> -&gt;hfsplus_file_extend<br /> -&gt;hfsplus_ext_read_extent<br /> -&gt;hfs_find_init<br /> -&gt;mutex_lock<br /> -&gt;hfsplus_free_extents<br /> WARN_ON(mutex_is_locked) !!!<br /> <br /> Several threads could try to lock the shared extents tree.<br /> And warning can be triggered in one thread when another thread<br /> has locked the tree. This is the wrong behavior of the code and<br /> we need to remove the warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Fix warning from KUnit tests<br /> <br /> get_id_range() expects a positive value as first argument but<br /> get_random_u8() can return 0. Fix this by clamping it.<br /> <br /> Validated by running the test in a for loop for 1000 times.<br /> <br /> Note that MAX() is wrong as it is only supposed to be used for<br /> constants, but max() is good here.<br /> <br /> [..] ok 9 test_range2_rand1<br /> [..] ok 10 test_range2_rand2<br /> [..] ok 11 test_range2_rand15<br /> [..] ------------[ cut here ]------------<br /> [..] WARNING: CPU: 6 PID: 104 at security/landlock/id.c:99 test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1))<br /> [..] Modules linked in:<br /> [..] CPU: 6 UID: 0 PID: 104 Comm: kunit_try_catch Tainted: G N 6.16.0-rc1-dev-00001-g314a2f98b65f #1 PREEMPT(undef)<br /> [..] Tainted: [N]=TEST<br /> [..] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [..] RIP: 0010:test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1))<br /> [..] Code: 49 c7 c0 10 70 30 82 4c 89 ff 48 c7 c6 a0 63 1e 83 49 c7 45 a0 e0 63 1e 83 e8 3f 95 17 00 e9 1f ff ff ff 0f 0b e9 df fd ff ff 0b ba 01 00 00 00 e9 68 fe ff ff 49 89 45 a8 49 8d 4d a0 45 31<br /> <br /> [..] RSP: 0000:ffff888104eb7c78 EFLAGS: 00010246<br /> [..] RAX: 0000000000000000 RBX: 000000000870822c RCX: 0000000000000000<br /> ^^^^^^^^^^^^^^^^<br /> [..]<br /> [..] Call Trace:<br /> [..]<br /> [..] ---[ end trace 0000000000000000 ]---<br /> [..] ok 12 test_range2_rand16<br /> [..] # landlock_id: pass:12 fail:0 skip:0 total:12<br /> [..] # Totals: pass:12 fail:0 skip:0 total:12<br /> [..] ok 1 landlock_id<br /> <br /> [mic: Minor cosmetic improvements]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: Fix potential NULL dereference on kmalloc failure<br /> <br /> Avoid potential NULL pointer dereference by checking the return value of<br /> kmalloc and handling allocation failure properly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix WARN_ON for monitor mode on some devices<br /> <br /> On devices without WANT_MONITOR_VIF (and probably without<br /> channel context support) we get a WARN_ON for changing the<br /> per-link setting of a monitor interface.<br /> <br /> Since we already skip AP_VLAN interfaces and MONITOR with<br /> WANT_MONITOR_VIF and/or NO_VIRTUAL_MONITOR should update<br /> the settings, catch this in the link change code instead<br /> of the warning.