Page 446 of 3339 results (0.009 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: ice: Fix DMA mappings leak Fix leak, when user changes ring parameters. During reallocation of RX buffers, new DMA mappings are created for those buffers. New buffers with different RX ring count should substitute older ones, but those buffers were freed in ice_vsi_cfg_rxq and reallocated again with ice_alloc_rx_buf. kfree on rx_buf caused leak of already mapped DMA. Reallocate ZC with xdp_buf struct, when BPF program loads. Reallocate back to rx_buf, when BPF program unloads. If BPF program is loaded/unloaded and XSK pools are created, reallocate RX queues accordingly in XDP_SETUP_XSK_POOL handler. Steps for reproduction: while : do for ((i=0; i<=8160; i=i+32)) do ethtool -G enp130s0f0 rx $i tx $i sleep 0.5 ethtool -g enp130s0f0 done done En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: Reparar fuga de asignaciones DMA. Reparar fuga cuando el usuario cambia los parámetros del anillo. Durante la reasignación de búferes RX, se crean nuevas asignaciones DMA para esos búferes. • https://git.kernel.org/stable/c/617f3e1b588c802517c236087561c6bcb0b4afd6 https://git.kernel.org/stable/c/07f40e9f0ff342eb3e97d5c544783b7cb641689c https://git.kernel.org/stable/c/7e753eb675f0523207b184558638ee2eed6c9ac2 •

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

In the Linux kernel, the following vulnerability has been resolved: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR In some case, the GDDV returns a package with a buffer which has zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10). Then the data_vault_read() got NULL point dereference problem when accessing the 0x10 value in data_vault. [ 71.024560] BUG: kernel NULL pointer dereference, address: 0000000000000010 This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or NULL value in data_vault. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Thermal/int340x_thermal: maneja data_vault cuando el valor es ZERO_SIZE_PTR. En algunos casos, el GDDV devuelve un paquete con un buffer que tiene longitud cero. Provoca que kmemdup() devuelva ZERO_SIZE_PTR (0x10). • https://git.kernel.org/stable/c/dae42083b045a4ddf71c57cf350cb2412b5915c2 https://git.kernel.org/stable/c/7931e28098a4c1a2a6802510b0cbe57546d2049d https://access.redhat.com/security/cve/CVE-2022-48703 https://bugzilla.redhat.com/show_bug.cgi?id=2278960 •

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc() The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however snd_emu10k1_pcm_channel_alloc() accesses the newly allocated voices as if it never wrapped around. This results in out of bounds access if the first voice has a high enough index so that first_voice + requested_voice_count > NUM_G (64). The more voices are requested, the more likely it is for this to occur. This was initially discovered using PipeWire, however it can be reproduced by calling aplay multiple times with 16 channels: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40 index 65 is out of range for type 'snd_emu10k1_voice [64]' CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7 Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x3f __ubsan_handle_out_of_bounds.cold+0x44/0x49 snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1] snd_pcm_hw_params+0x29f/0x600 [snd_pcm] snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm] ? exit_to_user_mode_prepare+0x35/0x170 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x26/0x50 ? do_syscall_64+0x69/0x90 ? • https://git.kernel.org/stable/c/637c5310acb48fffcc5657568db3f3e9bc719bfa https://git.kernel.org/stable/c/6b0e260ac3cf289e38446552461caa65e6dab275 https://git.kernel.org/stable/c/88aac6684cf8bc885cca15463cb4407e91f28ff7 https://git.kernel.org/stable/c/45321a7d02b7cf9b3f97e3987fc1e4d649b82da2 https://git.kernel.org/stable/c/39a90720f3abe96625d1224e7a7463410875de4c https://git.kernel.org/stable/c/45814a53514e10a8014906c882e0d0d38df39cc1 https://git.kernel.org/stable/c/4204a01ffce97cae1d59edc5848f02be5b2b9178 https://git.kernel.org/stable/c/d29f59051d3a07b81281b2df2b8c9dfe4 •

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

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface() There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and the number of it's interfaces less than 4, an out-of-bounds read bug occurs when parsing the interface descriptor for this device. Fix this by checking the number of interfaces. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: corrige un error fuera de los límites en __snd_usb_parse_audio_interface() Puede haber un dispositivo de audio USB defectuoso con una ID de USB de (0x04fa, 0x4201) y el Si el número de interfaces es inferior a 4, se produce un error de lectura fuera de límites al analizar el descriptor de interfaz para este dispositivo. Solucione este problema verificando la cantidad de interfaces. • https://git.kernel.org/stable/c/b970518014f2f0f6c493fb86c1e092b936899061 https://git.kernel.org/stable/c/91904870370fd986c29719846ed76d559de43251 https://git.kernel.org/stable/c/2a308e415d247a23d4d64c964c02e782eede2936 https://git.kernel.org/stable/c/0492798bf8dfcc09c9337a1ba065da1d1ca68712 https://git.kernel.org/stable/c/6123bec8480d23369e2ee0b2208611619f269faf https://git.kernel.org/stable/c/98e8e67395cc6d0cdf3a771f86ea42d0ee6e59dd https://git.kernel.org/stable/c/8293e61bbf908b18ff9935238d4fc2ad359e3fe0 https://git.kernel.org/stable/c/e53f47f6c1a56d2af728909f1cb894da6 •

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

In the Linux kernel, the following vulnerability has been resolved: vfio/type1: Unpin zero pages There's currently a reference count leak on the zero page. We increment the reference via pin_user_pages_remote(), but the page is later handled as an invalid/reserved page, therefore it's not accounted against the user and not unpinned by our put_pfn(). Introducing special zero page handling in put_pfn() would resolve the leak, but without accounting of the zero page, a single user could still create enough mappings to generate a reference count overflow. The zero page is always resident, so for our purposes there's no reason to keep it pinned. Therefore, add a loop to walk pages returned from pin_user_pages_remote() and unpin any zero pages. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vfio/type1: Desanclar páginas cero Actualmente hay una pérdida de recuento de referencias en la página cero. Incrementamos la referencia a través de pin_user_pages_remote(), pero la página luego se maneja como una página no válida/reservada, por lo tanto, no se contabiliza contra el usuario y nuestro put_pfn() no la desancla. • https://git.kernel.org/stable/c/578d644edc7d2c1ff53f7e4d0a25da473deb4a03 https://git.kernel.org/stable/c/5321908ef74fb593e0dbc8737d25038fc86c9986 https://git.kernel.org/stable/c/5d721bf222936f5cf3ee15ced53cc483ecef7e46 https://git.kernel.org/stable/c/873aefb376bbc0ed1dd2381ea1d6ec88106fdbd4 •