Page 55 of 2784 results (0.013 seconds)

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm95234) 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/93f0f5721d0cca45dac50af1ae6f9a9826c699fd https://git.kernel.org/stable/c/438453dfbbdcf4be26891492644aa3ecbb42c336 https://git.kernel.org/stable/c/59c1fb9874a01c9abc49a0a32f192a7e7b4e2650 https://git.kernel.org/stable/c/0fc27747633aa419f9af40e7bdfa00d2ec94ea81 https://git.kernel.org/stable/c/da765bebd90e1b92bdbc3c6a27a3f3cc81529ab6 https://git.kernel.org/stable/c/46e4fd338d5bdbaf60e41cda625b24949d2af201 https://git.kernel.org/stable/c/16f42953231be1e7be77bc24005270d9e0d9d2ee https://git.kernel.org/stable/c/af64e3e1537896337405f880c1e9ac1f8 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775-core) 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/298a55f11edd811f2189b74eb8f53dee34d4f14c https://git.kernel.org/stable/c/d6035c55fa9afefc23f85f57eff1d4a1d82c5b10 https://git.kernel.org/stable/c/8a1e958e26640ce015abdbb75c8896301b9bf398 https://git.kernel.org/stable/c/02bb3b4c7d5695ff4be01e0f55676bba49df435e https://git.kernel.org/stable/c/0c23e18cef20b989a9fd7cb0a745e1259b969159 https://git.kernel.org/stable/c/2f695544084a559f181cafdfd3f864c5ff9dd1db https://git.kernel.org/stable/c/996221b030995cc5f5baa4a642201d64b62a17cd https://git.kernel.org/stable/c/0403e10bf0824bf0ec2bb135d4cf1c0cc •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

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: 0

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: 0

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 •