CVSS: -EPSS: %CPEs: 10EXPL: 0CVE-2024-50236 – wifi: ath10k: Fix memory leak in management tx
https://notcve.org/view.php?id=CVE-2024-50236
In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8 [<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110 [<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400 [<ffffffe6e78d60b8>] worker_thread+0x208/0x328 [<ffffffe6e78dc890>] kthread+0x100/0x1c0 [<ffffffe6e78166c0>] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 • https://git.kernel.org/stable/c/dc405152bb64d4ae01c9ac669de25b2d1fb6fc2d https://git.kernel.org/stable/c/aea35bd40d64eff19f287b58e5c4a15a305f6607 https://git.kernel.org/stable/c/2bc8b1816cf4908ae0a04c3e87e167d2dcb60f38 https://git.kernel.org/stable/c/eff818238bedb9c2484c251ec46f9f160911cdc0 https://git.kernel.org/stable/c/6fc9af3df6ca7f3c94774d20f62dc7b49616026d https://git.kernel.org/stable/c/4112450da7d67b59ccedc2208bae622db17dbcb8 https://git.kernel.org/stable/c/705be2dc45c7f852e211e16bc41a916fab741983 https://git.kernel.org/stable/c/6cc23898e6ba47e976050d3c080b4d2c1 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-50235 – wifi: cfg80211: clear wdev->cqm_config pointer on free
https://notcve.org/view.php?id=CVE-2024-50235
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free. • https://git.kernel.org/stable/c/c797498e860e9a435a651bbf0789433684ce6dd8 https://git.kernel.org/stable/c/37c20b2effe987b806c8de6d12978e4ffeff026f https://git.kernel.org/stable/c/32fb9b7d98c3e586bddfb978d383aa8d2b1211bc https://git.kernel.org/stable/c/ba392e1355ba74b1d4fa11b85f71ab6ed7ecc058 https://git.kernel.org/stable/c/6c44abb2d4c3262737d5d67832daebc8cf48b8c9 https://git.kernel.org/stable/c/64e4c45d23cd7f6167f69cc2d2877bc7f54292e5 https://git.kernel.org/stable/c/d5fee261dfd9e17b08b1df8471ac5d5736070917 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2024-50234 – wifi: iwlegacy: Clear stale interrupts before resuming device
https://notcve.org/view.php?id=CVE-2024-50234
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 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 [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. • https://git.kernel.org/stable/c/271d282ecc15d7012e71ca82c89a6c0e13a063dd https://git.kernel.org/stable/c/9d89941e51259c2b0b8e9c10c6f1f74200d7444f https://git.kernel.org/stable/c/d0231f43df473e2f80372d0ca150eb3619932ef9 https://git.kernel.org/stable/c/8ac22fe1e2b104c37e4fecd97735f64bd6349ebc https://git.kernel.org/stable/c/23f9cef17ee315777dbe88d5c11ff6166e4d0699 https://git.kernel.org/stable/c/cedf0f1db8d5f3524339c2c6e35a8505b0f1ab73 https://git.kernel.org/stable/c/8af8294d369a871cdbcdbb4d13b87d2d6e490a1f https://git.kernel.org/stable/c/07c90acb071b9954e1fecb1e4f4f13d12 •
CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2024-50233 – staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()
https://notcve.org/view.php?id=CVE-2024-50233
In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value. • https://git.kernel.org/stable/c/ea707584bac187c9c6c64c4eacd1c09bcc08f37b https://git.kernel.org/stable/c/fcd6b59f7a774558e2525251c68aa37aff748e55 https://git.kernel.org/stable/c/442f786c5bff8cfd756ebdeaa4aadbf05c22aa5a https://git.kernel.org/stable/c/2f39548f45693d86e950647012a214da6917dc9f https://git.kernel.org/stable/c/ccbc10647aafe2b7506edb4b10e19c6c2416c162 https://git.kernel.org/stable/c/adfbc08b94e7df08b9ed5fa26b969cc1b54c84ec https://git.kernel.org/stable/c/dd9e1cf619c945f320e686dcaf13e37ef0b05fdd https://git.kernel.org/stable/c/6bd301819f8f69331a55ae2336c8b111f •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-50232 – iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()
https://notcve.org/view.php?id=CVE-2024-50232
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero. • https://git.kernel.org/stable/c/7b8d045e497a04dd88546da51f34fa3b102778d2 https://git.kernel.org/stable/c/4f588fffc307a4bc2761aee6ff275bb4b433e451 https://git.kernel.org/stable/c/f51343f346e6abde094548a7fb34472b0d4cae91 https://git.kernel.org/stable/c/3dc0eda2cd5c653b162852ae5f0631bfe4ca5e95 https://git.kernel.org/stable/c/0ac0beb4235a9a474f681280a3bd4e2a5bb66569 https://git.kernel.org/stable/c/efa353ae1b0541981bc96dbf2e586387d0392baa •