CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50237 – wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
https://notcve.org/view.php?id=CVE-2024-50237
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data • https://git.kernel.org/stable/c/5b3dc42b1b0db0264bbbe4ae44c15ab97bfd1e93 https://git.kernel.org/stable/c/b0b862aa3dbcd16b3c4715259a825f48ca540088 https://git.kernel.org/stable/c/78b698fbf37208ee921ee4cedea75b5d33d6ea9f https://git.kernel.org/stable/c/c21efba8b5a86537ccdf43f77536bad02f82776c https://git.kernel.org/stable/c/b2bcbe5450b20641f512d6b26c6b256a5a4f847f https://git.kernel.org/stable/c/8f6cd4d5bb7406656835a90e4f1a2192607f0c21 https://git.kernel.org/stable/c/ee35c423042c9e04079fdee3db545135d609d6ea https://git.kernel.org/stable/c/3ccf525a73d48e814634847f6d4a6150c •
CVSS: -EPSS: 0%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: 0%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: 0%CPEs: 8EXPL: 0CVE-2024-50230 – nilfs2: fix kernel bug due to missing clearing of checked flag
https://notcve.org/view.php?id=CVE-2024-50230
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files. • https://git.kernel.org/stable/c/8c26c4e2694a163d525976e804d81cd955bbb40c https://git.kernel.org/stable/c/994b2fa13a6c9cf3feca93090a9c337d48e3d60d https://git.kernel.org/stable/c/64afad73e4623308d8943645e5631f2c7a2d7971 https://git.kernel.org/stable/c/aa0cee46c5d3fd9a39575a4c8a4f65f25f095b89 https://git.kernel.org/stable/c/f05dbebb8ee34882505d53d83af7d18f28a49248 https://git.kernel.org/stable/c/cd0cdb51b15203fa27d4b714be83b7dfffa0b752 https://git.kernel.org/stable/c/f2f1fa446676c21edb777e6d2bc4fa8f956fab68 https://git.kernel.org/stable/c/56c6171932a7fb267ac6cb4ff8759b93e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50228 – mm: shmem: fix data-race in shmem_getattr()
https://notcve.org/view.php?id=CVE-2024-50228
In the Linux kernel, the following vulnerability has been resolved: mm: shmem: fix data-race in shmem_getattr() I got the following KCSAN report during syzbot testing: ================================================================== BUG: KCSAN: data-race in generic_fillattr / inode_set_ctime_current write to 0xffff888102eb3260 of 4 bytes by task 6565 on cpu 1: inode_set_ctime_to_ts include/linux/fs.h:1638 [inline] inode_set_ctime_current+0x169/0x1d0 fs/inode.c:2626 shmem_mknod+0x117/0x180 mm/shmem.c:3443 shmem_create+0x34/0x40 mm/shmem.c:3497 lookup_open fs/namei.c:3578 [inline] open_last_lookups fs/namei.c:3647 [inline] path_openat+0xdbc/0x1f00 fs/namei.c:3883 do_filp_open+0xf7/0x200 fs/namei.c:3913 do_sys_openat2+0xab/0x120 fs/open.c:1416 do_sys_open fs/open.c:1431 [inline] __do_sys_openat fs/open.c:1447 [inline] __se_sys_openat fs/open.c:1442 [inline] __x64_sys_openat+0xf3/0x120 fs/open.c:1442 x64_sys_call+0x1025/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:258 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e read to 0xffff888102eb3260 of 4 bytes by task 3498 on cpu 0: inode_get_ctime_nsec include/linux/fs.h:1623 [inline] inode_get_ctime include/linux/fs.h:1629 [inline] generic_fillattr+0x1dd/0x2f0 fs/stat.c:62 shmem_getattr+0x17b/0x200 mm/shmem.c:1157 vfs_getattr_nosec fs/stat.c:166 [inline] vfs_getattr+0x19b/0x1e0 fs/stat.c:207 vfs_statx_path fs/stat.c:251 [inline] vfs_statx+0x134/0x2f0 fs/stat.c:315 vfs_fstatat+0xec/0x110 fs/stat.c:341 __do_sys_newfstatat fs/stat.c:505 [inline] __se_sys_newfstatat+0x58/0x260 fs/stat.c:499 __x64_sys_newfstatat+0x55/0x70 fs/stat.c:499 x64_sys_call+0x141f/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:263 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e value changed: 0x2755ae53 -> 0x27ee44d3 Reported by Kernel Concurrency Sanitizer on: CPU: 0 UID: 0 PID: 3498 Comm: udevd Not tainted 6.11.0-rc6-syzkaller-00326-gd1f2d51b711a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 ================================================================== When calling generic_fillattr(), if you don't hold read lock, data-race will occur in inode member variables, which can cause unexpected behavior. Since there is no special protection when shmem_getattr() calls generic_fillattr(), data-race occurs by functions such as shmem_unlink() or shmem_mknod(). This can cause unexpected results, so commenting it out is not enough. Therefore, when calling generic_fillattr() from shmem_getattr(), it is appropriate to protect the inode using inode_lock_shared() and inode_unlock_shared() to prevent data-race. • https://git.kernel.org/stable/c/44a30220bc0a171c010e8df63d144655abdafe61 https://git.kernel.org/stable/c/9fb9703cd43ee20a6de8ccdef991677b7274cec0 https://git.kernel.org/stable/c/7cc30ada84323be19395094d567579536e0d187e https://git.kernel.org/stable/c/bda1a99a0dd644f31a87d636ac624eeb975cb65a https://git.kernel.org/stable/c/3d9528484480e8f4979b3a347930ed383be99f89 https://git.kernel.org/stable/c/82cae1e30bd940253593c2d4f16d88343d1358f4 https://git.kernel.org/stable/c/edd1f905050686fdc4cfe233d818469fdf7d5ff8 https://git.kernel.org/stable/c/ffd56612566bc23877c8f45def2801f33 •