Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix general protection fault in run_is_mapped_full<br /> <br /> Fixed deleating of a non-resident attribute in ntfs_create_inode()<br /> rollback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Additional check in ni_clear()<br /> <br /> Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to<br /> uninitialized bitmap during replay process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix possible deadlock in mi_read<br /> <br /> Mutex lock with another subclass used in ni_lock_dir().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Check if more than chunk-size bytes are written<br /> <br /> A incorrectly formatted chunk may decompress into<br /> more than LZNT_CHUNK_SIZE bytes and a index out of bounds<br /> will occur in s_max_off.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: CPPC: Make rmw_lock a raw_spin_lock<br /> <br /> The following BUG was triggered:<br /> <br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.12.0-rc2-XXX #406 Not tainted<br /> -----------------------------<br /> kworker/1:1/62 is trying to lock:<br /> ffffff8801593030 (&amp;cpc_ptr-&gt;rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 2 locks held by kworker/1:1/62:<br /> #0: ffffff897ef5ec98 (&amp;rq-&gt;__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50<br /> #1: ffffff880154e238 (&amp;sg_policy-&gt;update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280<br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406<br /> Workqueue: 0x0 (events)<br /> Call trace:<br /> dump_backtrace+0xa4/0x130<br /> show_stack+0x20/0x38<br /> dump_stack_lvl+0x90/0xd0<br /> dump_stack+0x18/0x28<br /> __lock_acquire+0x480/0x1ad8<br /> lock_acquire+0x114/0x310<br /> _raw_spin_lock+0x50/0x70<br /> cpc_write+0xcc/0x370<br /> cppc_set_perf+0xa0/0x3a8<br /> cppc_cpufreq_fast_switch+0x40/0xc0<br /> cpufreq_driver_fast_switch+0x4c/0x218<br /> sugov_update_shared+0x234/0x280<br /> update_load_avg+0x6ec/0x7b8<br /> dequeue_entities+0x108/0x830<br /> dequeue_task_fair+0x58/0x408<br /> __schedule+0x4f0/0x1070<br /> schedule+0x54/0x130<br /> worker_thread+0xc0/0x2e8<br /> kthread+0x130/0x148<br /> ret_from_fork+0x10/0x20<br /> <br /> sugov_update_shared() locks a raw_spinlock while cpc_write() locks a<br /> spinlock.<br /> <br /> To have a correct wait-type order, update rmw_lock to a raw spinlock and<br /> ensure that interrupts will be disabled on the CPU holding it.<br /> <br /> [ rjw: Changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fsdax: dax_unshare_iter needs to copy entire blocks<br /> <br /> The code that copies data from srcmap to iomap in dax_unshare_iter is<br /> very very broken, which bfoster&amp;#39;s recent fsx changes have exposed.<br /> <br /> If the pos and len passed to dax_file_unshare are not aligned to an<br /> fsblock boundary, the iter pos and length in the _iter function will<br /> reflect this unalignment.<br /> <br /> dax_iomap_direct_access always returns a pointer to the start of the<br /> kmapped fsdax page, even if its pos argument is in the middle of that<br /> page. This is catastrophic for data integrity when iter-&gt;pos is not<br /> aligned to a page, because daddr/saddr do not point to the same byte in<br /> the file as iter-&gt;pos. Hence we corrupt user data by copying it to the<br /> wrong place.<br /> <br /> If iter-&gt;pos + iomap_length() in the _iter function not aligned to a<br /> page, then we fail to copy a full block, and only partially populate the<br /> destination block. This is catastrophic for data confidentiality<br /> because we expose stale pmem contents.<br /> <br /> Fix both of these issues by aligning copy_pos/copy_len to a page<br /> boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that<br /> we always copy full blocks.<br /> <br /> We&amp;#39;re not done yet -- there&amp;#39;s no call to invalidate_inode_pages2_range,<br /> so programs that have the file range mmap&amp;#39;d will continue accessing the<br /> old memory mapping after the file metadata updates have completed.<br /> <br /> Be careful with the return value -- if the unshare succeeds, we still<br /> need to return the number of bytes that the iomap iter thinks we&amp;#39;re<br /> operating on.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_payload: sanitize offset and length before calling skb_checksum()<br /> <br /> If access to offset + length is larger than the skbuff length, then<br /> skb_checksum() triggers BUG_ON().<br /> <br /> skb_checksum() internally subtracts the length parameter while iterating<br /> over skbuff, BUG_ON(len) at the end of it checks that the expected<br /> length to be included in the checksum calculation is fully consumed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address<br /> <br /> The device stores IPv6 addresses that are used for encapsulation in<br /> linear memory that is managed by the driver.<br /> <br /> Changing the remote address of an ip6gre net device never worked<br /> properly, but since cited commit the following reproducer [1] would<br /> result in a warning [2] and a memory leak [3]. The problem is that the<br /> new remote address is never added by the driver to its hash table (and<br /> therefore the device) and the old address is never removed from it.<br /> <br /> Fix by programming the new address when the configuration of the ip6gre<br /> net device changes and removing the old one. If the address did not<br /> change, then the above would result in increasing the reference count of<br /> the address and then decreasing it.<br /> <br /> [1]<br /> # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit<br /> # ip link set dev bla type ip6gre remote 2001:db8:3::1<br /> # ip link del dev bla<br /> # devlink dev reload pci/0000:01:00.0<br /> <br /> [2]<br /> WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151<br /> Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023<br /> RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0<br /> [...]<br /> Call Trace:<br /> <br /> mlxsw_sp_router_netdevice_event+0x55f/0x1240<br /> notifier_call_chain+0x5a/0xd0<br /> call_netdevice_notifiers_info+0x39/0x90<br /> unregister_netdevice_many_notify+0x63e/0x9d0<br /> rtnl_dellink+0x16b/0x3a0<br /> rtnetlink_rcv_msg+0x142/0x3f0<br /> netlink_rcv_skb+0x50/0x100<br /> netlink_unicast+0x242/0x390<br /> netlink_sendmsg+0x1de/0x420<br /> ____sys_sendmsg+0x2bd/0x320<br /> ___sys_sendmsg+0x9a/0xe0<br /> __sys_sendmsg+0x7a/0xd0<br /> do_syscall_64+0x9e/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> [3]<br /> unreferenced object 0xffff898081f597a0 (size 32):<br /> comm "ip", pid 1626, jiffies 4294719324<br /> hex dump (first 32 bytes):<br /> 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ...............<br /> 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia.............<br /> backtrace (crc fd9be911):<br /> [] __kmalloc_cache_noprof+0x1da/0x260<br /> [] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340<br /> [] mlxsw_sp_router_netdevice_event+0x47b/0x1240<br /> [] notifier_call_chain+0x5a/0xd0<br /> [] call_netdevice_notifiers_info+0x39/0x90<br /> [] register_netdevice+0x5f7/0x7a0<br /> [] ip6gre_newlink_common.isra.0+0x65/0x130<br /> [] ip6gre_newlink+0x72/0x120<br /> [] rtnl_newlink+0x471/0xa20<br /> [] rtnetlink_rcv_msg+0x142/0x3f0<br /> [] netlink_rcv_skb+0x50/0x100<br /> [] netlink_unicast+0x242/0x390<br /> [] netlink_sendmsg+0x1de/0x420<br /> [] ____sys_sendmsg+0x2bd/0x320<br /> [] ___sys_sendmsg+0x9a/0xe0<br /> [] __sys_sendmsg+0x7a/0xd0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()<br /> <br /> modprobe iio-test-gts and rmmod it, then the following memory leak<br /> occurs:<br /> <br /> unreferenced object 0xffffff80c810be00 (size 64):<br /> comm "kunit_try_catch", pid 1654, jiffies 4294913981<br /> hex dump (first 32 bytes):<br /> 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@...<br /> 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................<br /> backtrace (crc a63d875e):<br /> [] kmemleak_alloc+0x34/0x40<br /> [] __kmalloc_noprof+0x2bc/0x3c0<br /> [] devm_iio_init_iio_gts+0x4b4/0x16f4<br /> [] 0xffffffdf052a62e0<br /> [] 0xffffffdf052a6488<br /> [] kunit_try_run_case+0x13c/0x3ac<br /> [] kunit_generic_run_threadfn_adapter+0x80/0xec<br /> [] kthread+0x2e8/0x374<br /> [] ret_from_fork+0x10/0x20<br /> unreferenced object 0xffffff80cbfe9e70 (size 16):<br /> comm "kunit_try_catch", pid 1658, jiffies 4294914015<br /> hex dump (first 16 bytes):<br /> 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@...........<br /> backtrace (crc 857f0cb4):<br /> [] kmemleak_alloc+0x34/0x40<br /> [] __kmalloc_noprof+0x2bc/0x3c0<br /> [] devm_iio_init_iio_gts+0x4b4/0x16f4<br /> [] 0xffffffdf052a62e0<br /> [] 0xffffffdf052a6864<br /> [] kunit_try_run_case+0x13c/0x3ac<br /> [] kunit_generic_run_threadfn_adapter+0x80/0xec<br /> [] kthread+0x2e8/0x374<br /> [] ret_from_fork+0x10/0x20<br /> ......<br /> <br /> It includes 5*5 times "size 64" memory leaks, which correspond to 5 times<br /> test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int))<br /> and gts_test_itimes size 5. It also includes 5*1 times "size 16"<br /> memory leak, which correspond to one time __test_init_iio_gain_scale()<br /> call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes<br /> size 5.<br /> <br /> The reason is that the per_time_gains[i] is not freed which is allocated in<br /> the "gts-&gt;num_itime" for loop in iio_gts_build_avail_scale_table().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend<br /> <br /> Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation")<br /> removed most users of the platform device driver data from the<br /> qcom-qmp-usb driver, but mistakenly also removed the initialisation<br /> despite the data still being used in the runtime PM callbacks. This bug<br /> was later reproduced when the driver was copied to create the qmp-usbc<br /> driver.<br /> <br /> Restore the driver data initialisation at probe to avoid a NULL-pointer<br /> dereference on runtime suspend.<br /> <br /> Apparently no one uses runtime PM, which currently needs to be enabled<br /> manually through sysfs, with these drivers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend<br /> <br /> Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation")<br /> removed most users of the platform device driver data from the<br /> qcom-qmp-usb driver, but mistakenly also removed the initialisation<br /> despite the data still being used in the runtime PM callbacks. This bug<br /> was later reproduced when the driver was copied to create the<br /> qmp-usb-legacy driver.<br /> <br /> Restore the driver data initialisation at probe to avoid a NULL-pointer<br /> dereference on runtime suspend.<br /> <br /> Apparently no one uses runtime PM, which currently needs to be enabled<br /> manually through sysfs, with these drivers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom: qmp-usb: fix NULL-deref on runtime suspend<br /> <br /> Commit 413db06c05e7 ("phy: qcom-qmp-usb: clean up probe initialisation")<br /> removed most users of the platform device driver data, but mistakenly<br /> also removed the initialisation despite the data still being used in the<br /> runtime PM callbacks.<br /> <br /> Restore the driver data initialisation at probe to avoid a NULL-pointer<br /> dereference on runtime suspend.<br /> <br /> Apparently no one uses runtime PM, which currently needs to be enabled<br /> manually through sysfs, with this driver.