CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46756 – hwmon: (w83627ehf) Fix underflows seen when writing limit attributes
https://notcve.org/view.php?id=CVE-2024-46756
In the Linux kernel, the following vulnerability has been resolved: hwmon: (w83627ehf) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. • https://git.kernel.org/stable/c/93cf73a7bfdce683bde3a7bb65f270d3bd24497b https://git.kernel.org/stable/c/77ab0fd231c4ca873ec6908e761970360acc6df2 https://git.kernel.org/stable/c/56cfdeb2c77291f0b5e4592731adfb6ca8fc7c24 https://git.kernel.org/stable/c/cc4be794c8d8c253770103e097ab9dbdb5f99ae1 https://git.kernel.org/stable/c/d92f0baf99a7e327dcceab37cce57c38aab1f691 https://git.kernel.org/stable/c/8fecb75bff1b7d87a071c32a37aa0700f2be379d https://git.kernel.org/stable/c/26825b62bd1bd3e53b4f44e0745cb516d5186343 https://git.kernel.org/stable/c/5c1de37969b7bc0abcb20b86e91e70cae •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46755 – wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()
https://notcve.org/view.php?id=CVE-2024-46755
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id() mwifiex_get_priv_by_id() returns the priv pointer corresponding to the bss_num and bss_type, but without checking if the priv is actually currently in use. Unused priv pointers do not have a wiphy attached to them which can lead to NULL pointer dereferences further down the callstack. Fix this by returning only used priv pointers which have priv->bss_mode set to something else than NL80211_IFTYPE_UNSPECIFIED. Said NULL pointer dereference happened when an Accesspoint was started with wpa_supplicant -i mlan0 with this config: network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" } When waiting for the AP to be established, interrupting wpa_supplicant with <ctrl-c> and starting it again this happens: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000 | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18 | Hardware name: somemachine (DT) | Workqueue: events sdio_irq_work | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex] | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157 | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Call trace: | mwifiex_get_cfp+0xd8/0x15c [mwifiex] | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex] | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex] | mwifiex_process_sta_event+0x298/0xf0c [mwifiex] | mwifiex_process_event+0x110/0x238 [mwifiex] | mwifiex_main_process+0x428/0xa44 [mwifiex] | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio] | process_sdio_pending_irqs+0x64/0x1b8 | sdio_irq_work+0x4c/0x7c | process_one_work+0x148/0x2a0 | worker_thread+0x2fc/0x40c | kthread+0x110/0x114 | ret_from_fork+0x10/0x20 | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ end trace 0000000000000000 ]--- • https://git.kernel.org/stable/c/a12cf97cbefa139ef8d95081f2ea047cbbd74b7a https://git.kernel.org/stable/c/d834433ff313838a259bb6607055ece87b895b66 https://git.kernel.org/stable/c/9813770f25855b866b8ead8155b8806b2db70f6d https://git.kernel.org/stable/c/cb67b2e51b75f1a17bee7599c8161b96e1808a70 https://git.kernel.org/stable/c/1a05d8d02cfa3540ea5dbd6b39446bd3f515521f https://git.kernel.org/stable/c/c2618dcb26c7211342b54520b5b148c0d3471c8a https://git.kernel.org/stable/c/c16916dd6c16fa7e13ca3923eb6b9f50d848ad03 https://git.kernel.org/stable/c/c145eea2f75ff7949392aebecf7ef0a81 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46754 – bpf: Remove tst_run from lwt_seg6local_prog_ops.
https://notcve.org/view.php?id=CVE-2024-46754
In the Linux kernel, the following vulnerability has been resolved: bpf: Remove tst_run from lwt_seg6local_prog_ops. The syzbot reported that the lwt_seg6 related BPF ops can be invoked via bpf_test_run() without without entering input_action_end_bpf() first. Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL probably didn't work since it was introduced in commit 04d4b274e2a ("ipv6: sr: Add seg6local action End.BPF"). The reason is that the per-CPU variable seg6_bpf_srh_states::srh is never assigned in the self test case but each BPF function expects it. Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL. • https://git.kernel.org/stable/c/004d4b274e2a1a895a0e5dc66158b90a7d463d44 https://git.kernel.org/stable/c/9cd15511de7c619bbd0f54bb3f28e6e720ded5d6 https://git.kernel.org/stable/c/c13fda93aca118b8e5cd202e339046728ee7dddb •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46753 – btrfs: handle errors from btrfs_dec_ref() properly
https://notcve.org/view.php?id=CVE-2024-46753
In the Linux kernel, the following vulnerability has been resolved: btrfs: handle errors from btrfs_dec_ref() properly In walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This is incorrect, we have proper error handling here, return the error. • https://git.kernel.org/stable/c/a7f16a7a709845855cb5a0e080a52bda5873f9de https://git.kernel.org/stable/c/5eb178f373b4f16f3b42d55ff88fc94dd95b93b1 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-46752 – btrfs: replace BUG_ON() with error handling at update_ref_for_cow()
https://notcve.org/view.php?id=CVE-2024-46752
In the Linux kernel, the following vulnerability has been resolved: btrfs: replace BUG_ON() with error handling at update_ref_for_cow() Instead of a BUG_ON() just return an error, log an error message and abort the transaction in case we find an extent buffer belonging to the relocation tree that doesn't have the full backref flag set. This is unexpected and should never happen (save for bugs or a potential bad memory). • https://git.kernel.org/stable/c/b50857b96429a09fd3beed9f7f21b7bb7c433688 https://git.kernel.org/stable/c/0fbac73a97286a7ec72229cb9b42d760a2c717ac https://git.kernel.org/stable/c/41a0f85e268d72fe04f731b8ceea4748c2d65491 https://git.kernel.org/stable/c/f895db00c65e5d77c437cce946da9ec29dcdf563 https://git.kernel.org/stable/c/b56329a782314fde5b61058e2a25097af7ccb675 •