Page 152 of 871 results (0.004 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: udf: Fix bogus checksum computation in udf_rename() Syzbot reports uninitialized memory access in udf_rename() when updating checksum of '..' directory entry of a moved directory. This is indeed true as we pass on-stack diriter.fi to the udf_update_tag() and because that has only struct fileIdentDesc included in it and not the impUse or name fields, the checksumming function is going to checksum random stack contents beyond the end of the structure. This is actually harmless because the following udf_fiiter_write_fi() will recompute the checksum from on-disk buffers where everything is properly included. So all that is needed is just removing the bogus calculation. • https://git.kernel.org/stable/c/9616d00140a1cdf0bfa557019b36923dc7796942 https://git.kernel.org/stable/c/e9109a92d2a95889498bed3719cd2318892171a2 https://git.kernel.org/stable/c/c996b570305e7a6910c2ce4cdcd4c22757ffe241 https://git.kernel.org/stable/c/fe2ead240c31e8d158713beca9d0681a6e6a53ab https://git.kernel.org/stable/c/40d7b3ed52449d36143bab8d3e70926aa61a60f4 https://git.kernel.org/stable/c/27ab33854873e6fb958cb074681a0107cc2ecc4c https://git.kernel.org/stable/c/9c439311c13fc6faab1921441165c9b8b500c83b •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: wow: fix GTK offload H2C skbuff issue We mistakenly put skb too large and that may exceed skb->end. Therefore, we fix it. skbuff: skb_over_panic: text:ffffffffc09e9a9d len:416 put:204 head:ffff8fba04eca780 data:ffff8fba04eca7e0 tail:0x200 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4747 Comm: kworker/u4:44 Tainted: G O 6.6.30-02659-gc18865c4dfbd #1 86547039b47e46935493f615ee31d0b2d711d35e Hardware name: HP Meep/Meep, BIOS Google_Meep.11297.262.0 03/18/2021 Workqueue: events_unbound async_run_entry_fn RIP: 0010:skb_panic+0x5d/0x60 Code: c6 63 8b 8f bb 4c 0f 45 f6 48 c7 c7 4d 89 8b bb 48 89 ce 44 89 d1 41 56 53 41 53 ff b0 c8 00 00 00 e8 27 5f 23 00 48 83 c4 20 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 RSP: 0018:ffffaa700144bad0 EFLAGS: 00010282 RAX: 0000000000000089 RBX: 0000000000000140 RCX: 14432c5aad26c900 RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffaa700144bae0 R08: 0000000000000000 R09: ffffaa700144b920 R10: 00000000ffffdfff R11: ffffffffbc28fbc0 R12: ffff8fba4e57a010 R13: 0000000000000000 R14: ffffffffbb8f8b63 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8fba7bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007999c4ad1000 CR3: 000000015503a000 CR4: 0000000000350ee0 Call Trace: <TASK> ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? • https://git.kernel.org/stable/c/ed9a3c0d4dd9ce79ff7f65238164a96da1b52dbf https://git.kernel.org/stable/c/ef0d9d2f0dc1133db3d3a1c5167190c6627146b2 https://git.kernel.org/stable/c/dda364c345913fe03ddbe4d5ae14a2754c100296 •

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

In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix out-of-bounds issue when preparing trampoline image We get the size of the trampoline image during the dry run phase and allocate memory based on that size. The allocated image will then be populated with instructions during the real patch phase. But after commit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), the `im` argument is inconsistent in the dry run and real patch phase. This may cause emit_imm in RV64 to generate a different number of instructions when generating the 'im' address, potentially causing out-of-bounds issues. Let's emit the maximum number of instructions for the "im" address during dry run to fix this problem. • https://git.kernel.org/stable/c/26ef208c209a0e6eed8942a5d191b39dccfa6e38 https://git.kernel.org/stable/c/3e6a1b1b179abb643ec3560c02bc3082bc92285f https://git.kernel.org/stable/c/9f1e16fb1fc9826001c69e0551d51fbbcd2d74e9 •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() In rtw89_sta_info_get_iter() 'status->he_gi' is compared to array size. But then 'rate->he_gi' is used as array index instead of 'status->he_gi'. This can lead to go beyond array boundaries in case of 'rate->he_gi' is not equal to 'status->he_gi' and is bigger than array size. Looks like "copy-paste" mistake. Fix this mistake by replacing 'rate->he_gi' with 'status->he_gi'. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd https://git.kernel.org/stable/c/a2a095c08b95372d6d0c5819b77f071af5e75366 https://git.kernel.org/stable/c/7a0edc3d83aff3a48813d78c9cad9daf38decc74 https://git.kernel.org/stable/c/96ae4de5bc4c8ba39fd072369398f59495b73f58 https://git.kernel.org/stable/c/85099c7ce4f9e64c66aa397cd9a37473637ab891 •

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

In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: avoid reporting connection success with wrong SSID When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found). The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning. Fixed it by checking the SSID (from user space) in the connection code. • https://git.kernel.org/stable/c/c7cdba31ed8b87526db978976392802d3f93110c https://git.kernel.org/stable/c/994fc2164a03200c3bf42fb45b3d49d9d6d33a4d https://git.kernel.org/stable/c/05c4488a0e446c6ccde9f22b573950665e1cd414 https://git.kernel.org/stable/c/93e898a264b4e0a475552ba9f99a016eb43ef942 https://git.kernel.org/stable/c/d3cc85a10abc8eae48988336cdd3689ab92581b3 https://git.kernel.org/stable/c/36e92b5edc8e0daa18e9325674313802ce3fbc29 https://git.kernel.org/stable/c/416d3c1538df005195721a200b0371d39636e05d https://git.kernel.org/stable/c/b5d14b0c6716fad7f0c94ac6e1d6f60a4 •