NVD CVE LIST BY VENDOR

---

VENDOR: LINUX

---

VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: HIGH
CVE ID..............: CVE-2024-50067
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-50067
DATE LAST MODIFIED..: 2024-10-29T16:30Z
ORIGINAL CVE DATE...: 2024-10-28T01:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/373b9338c9722a368925d83bc622c596896b328e

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: uprobe: avoid out-of-bounds memory access of fetching args Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem. Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access. It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c ``` \#include stdio.h \#include stdlib.h \#include string.h // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf("%s\n", str); } int main() { char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0; } ``` 3. compile program `gcc -o test test.c` 4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string ``` 5. configure uprobe with offset 0x1199 ``` off=0x1199 cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" uprobe_events echo 1 events/uprobes/enable echo 1 tracing_on ``` 6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: TASK dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ? __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ? __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 /TASK This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: MEDIUM
CVE ID..............: CVE-2022-48949
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48949
DATE LAST MODIFIED..: 2024-10-29T16:32Z
ORIGINAL CVE DATE...: 2024-10-21T20:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/a6629659af3f5c6a91e3914ea62554c975ab77f4

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: HIGH
CVE ID..............: CVE-2022-48948
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48948
DATE LAST MODIFIED..: 2024-10-29T16:34Z
ORIGINAL CVE DATE...: 2024-10-21T20:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req-actual bytes to uvc_event-data.data array of size 60. This may result in an overflow of 4 bytes.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: MEDIUM
CVE ID..............: CVE-2024-49999
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-49999
DATE LAST MODIFIED..: 2024-10-29T18:03Z
ORIGINAL CVE DATE...: 2024-10-21T18:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/3d51ab44123f35dd1d646d99a15ebef10f55e263

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op-server might be NULL, but we don't check that before attempting to set the server flag.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: HIGH
CVE ID..............: CVE-2024-49997
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-49997
DATE LAST MODIFIED..: 2024-10-29T16:20Z
ORIGINAL CVE DATE...: 2024-10-21T18:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/185df159843d30fb71f821e7ea4368c2a3bfcd36

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: HIGH
CVE ID..............: CVE-2024-49984
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-49984
DATE LAST MODIFIED..: 2024-10-29T16:22Z
ORIGINAL CVE DATE...: 2024-10-21T18:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/73ad583bd4938bf37d2709fc36901eb6f22f2722

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Prevent out of bounds access in performance query extensions Check that the number of perfmons userspace is passing in the copy and reset extensions is not greater than the internal kernel storage where the ids will be copied into.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: HIGH
CVE ID..............: CVE-2024-49983
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-49983
DATE LAST MODIFIED..: 2024-10-29T16:23Z
ORIGINAL CVE DATE...: 2024-10-21T18:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/8c26d9e53e5fbacda0732a577e97c5a5b7882aaf

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth path[0].p_maxdepth) kfree(path) --- path First freed *orig_path = path = NULL --- null ppath kfree(path) --- path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: MEDIUM
CVE ID..............: CVE-2024-49979
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-49979
DATE LAST MODIFIED..: 2024-10-29T18:02Z
ORIGINAL CVE DATE...: 2024-10-21T18:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/3fdd8c83e83fa5e82f1b5585245c51e0355c9f46

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg-next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: MEDIUM
CVE ID..............: CVE-2024-49978
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-49978
DATE LAST MODIFIED..: 2024-10-29T18:01Z
ORIGINAL CVE DATE...: 2024-10-21T18:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/080e6c9a3908de193a48f646c5ce1bfb15676ffc

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg-next)-dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: MEDIUM
CVE ID..............: CVE-2024-49970
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-49970
DATE LAST MODIFIED..: 2024-10-29T15:57Z
ORIGINAL CVE DATE...: 2024-10-21T18:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/b219b46ad42df1dea9258788bcfea37181f3ccb2

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 = 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 = 5


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: HIGH
CVE ID..............: CVE-2024-43843
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-43843
DATE LAST MODIFIED..: 2024-10-29T16:29Z
ORIGINAL CVE DATE...: 2024-08-17T10:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/3e6a1b1b179abb643ec3560c02bc3082bc92285f

CVE DESCRIPTION.....: 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.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: LOW
CVE ID..............: CVE-2024-43841
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-43841
DATE LAST MODIFIED..: 2024-10-29T16:27Z
ORIGINAL CVE DATE...: 2024-08-17T10:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/d3cc85a10abc8eae48988336cdd3689ab92581b3

CVE DESCRIPTION.....: 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.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: MEDIUM
CVE ID..............: CVE-2024-43840
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-43840
DATE LAST MODIFIED..: 2024-10-29T16:25Z
ORIGINAL CVE DATE...: 2024-08-17T10:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/6d218fcc707d6b2c3616b6cd24b948fd4825cfec

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG When BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls __bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them the struct bpf_tramp_image *im pointer as an argument in R0. The trampoline generation code uses emit_addr_mov_i64() to emit instructions for moving the bpf_tramp_image address into R0, but emit_addr_mov_i64() assumes the address to be in the vmalloc() space and uses only 48 bits. Because bpf_tramp_image is allocated using kzalloc(), its address can use more than 48-bits, in this case the trampoline will pass an invalid address to __bpf_tramp_enter/exit() causing a kernel crash. Fix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64() as it can work with addresses that are greater than 48-bits.


VENDOR PRODUCT(S)...: LINUX KERNEL
CVE SEVERITY........: MEDIUM
CVE ID..............: CVE-2024-43838
NIST REFERENCE URL..: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-43838
DATE LAST MODIFIED..: 2024-10-29T16:24Z
ORIGINAL CVE DATE...: 2024-08-17T10:15Z
REFERENCE URL.......: https://git.kernel.org/stable/c/345652866a8869825a2a582ee5a28d75141f184a

CVE DESCRIPTION.....: In the Linux kernel, the following vulnerability has been resolved: bpf: fix overflow check in adjust_jmp_off() adjust_jmp_off() incorrectly used the insn-imm field for all overflow check, which is incorrect as that should only be done or the BPF_JMP32 | BPF_JA case, not the general jump instruction case. Fix it by using insn-off for overflow check in the general case.