Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Initialize struct nfsd4_copy earlier<br /> <br /> Ensure the refcount and async_copies fields are initialized early.<br /> cleanup_async_copy() will reference these fields if an error occurs<br /> in nfsd4_copy(). If they are not correctly initialized, at the very<br /> least, a refcount underflow occurs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()<br /> <br /> In the ad7124_write_raw() function, parameter val can potentially<br /> be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST()<br /> is called within ad7124_set_channel_odr(). The ad7124_write_raw()<br /> function is invoked through the sequence: iio_write_channel_raw() -&gt;<br /> iio_write_channel_attribute() -&gt; iio_channel_write(), with no checks<br /> in place to ensure val is non-zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()<br /> <br /> In the ad9832_write_frequency() function, clk_get_rate() might return 0.<br /> This can lead to a division by zero when calling ad9832_calc_freqreg().<br /> The check if (fout &gt; (clk_get_rate(st-&gt;mclk) / 2)) does not protect<br /> against the case when fout is 0. The ad9832_write_frequency() function<br /> is called from ad9832_write(), and fout is derived from a text buffer,<br /> which can contain any value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlegacy: Clear stale interrupts before resuming device<br /> <br /> iwl4965 fails upon resume from hibernation on my laptop. The reason<br /> seems to be a stale interrupt which isn&amp;#39;t being cleared out before<br /> interrupts are enabled. We end up with a race beween the resume<br /> trying to bring things back up, and the restart work (queued form<br /> the interrupt handler) trying to bring things down. Eventually<br /> the whole thing blows up.<br /> <br /> Fix the problem by clearing out any stale interrupts before<br /> interrupts get enabled during resume.<br /> <br /> Here&amp;#39;s a debug log of the indicent:<br /> [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000<br /> [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000<br /> [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio.<br /> [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload<br /> [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282<br /> [ 12.052207] ieee80211 phy0: il4965_mac_start enter<br /> [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff<br /> [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready<br /> [ 12.052324] ieee80211 phy0: il_apm_init Init card&amp;#39;s basic functions<br /> [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S<br /> [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm<br /> [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm<br /> [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK<br /> [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations<br /> [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up<br /> [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done.<br /> [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down<br /> [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout<br /> [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort<br /> [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver<br /> [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared<br /> [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state<br /> [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master<br /> [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear.<br /> [ 12.058869] ieee80211 phy0: Hardware restart was requested<br /> [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms.<br /> [ 16.132303] ------------[ cut here ]------------<br /> [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.<br /> [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211]<br /> [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev<br /> [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143<br /> [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010<br /> [ 16.132463] Workqueue: async async_run_entry_fn<br /> [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211]<br /> [ 16.132501] Code: da 02 00 0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: clear wdev-&gt;cqm_config pointer on free<br /> <br /> When we free wdev-&gt;cqm_config when unregistering, we also<br /> need to clear out the pointer since the same wdev/netdev<br /> may get re-registered in another network namespace, then<br /> destroyed later, running this code again, which results in<br /> a double-free.