Page 198 of 2864 results (0.021 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: send: handle path ref underflow in header iterate_inode_ref() Change BUG_ON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: enviar: manejar el desbordamiento de la referencia de ruta en el encabezado iterate_inode_ref() Cambie BUG_ON al manejo adecuado de errores si falla la creación del búfer de ruta. Los punteros no se imprimen para no filtrar accidentalmente las direcciones del kernel. • https://git.kernel.org/stable/c/be2b6bcc936ae17f42fff6494106a5660b35d8d3 https://git.kernel.org/stable/c/024529c27c8b4b273325a169e078337c8279e229 https://git.kernel.org/stable/c/4720d590c4cb5d9ffa0060b89743651cc7e995f9 https://git.kernel.org/stable/c/2f6174fd4ccf403b42b3d5f0d1b6b496a0e5330a https://git.kernel.org/stable/c/9ae356c627b493323e1433dcb27a26917668c07c https://git.kernel.org/stable/c/c1363ed8867b81ea169fba2ccc14af96a85ed183 https://git.kernel.org/stable/c/03938619a1e718b6168ae4528e1b0f979293f1a5 https://git.kernel.org/stable/c/3c6ee34c6f9cd12802326da26631232a6 •

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

In the Linux kernel, the following vulnerability has been resolved: net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list() Many syzbot reports show extreme rtnl pressure, and many of them hint that smc acquires rtnl in netns creation for no good reason [1] This patch returns early from smc_pnet_net_init() if there is no netdevice yet. I am not even sure why smc_pnet_create_pnetids_list() even exists, because smc_pnet_netdev_event() is also calling smc_pnet_add_base_pnetid() when handling NETDEV_UP event. [1] extract of typical syzbot reports 2 locks held by syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.1/12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 locks held by syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: reduce la presión rtnl en smc_pnet_create_pnetids_list() Muchos informes de syzbot muestran una presión rtnl extrema, y muchos de ellos insinúan que smc adquiere rtnl en la creación de netns sin una buena razón [1] Este parche regresa temprano desde smc_pnet_net_init() si aún no hay un netdevice. Ni siquiera estoy seguro de por qué existe smc_pnet_create_pnetids_list(), porque smc_pnet_netdev_event() también llama a smc_pnet_add_base_pnetid() cuando maneja el evento NETDEV_UP. [1] extracto de informes típicos de syzbot 2 bloqueos mantenidos por syz-executor.3/12252: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core /net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+ .+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.4/12253: #0: ffffffff8f369610 (pernet_ops_rwsem){+++ +}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/ smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.1/12257: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex ){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en : smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.2/12261: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns +0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1 : ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.0/12265: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3 }, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet. c:878 2 bloqueos retenidos por syz-executor.3/12268: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c: 491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}- {3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.4/12271: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3 :3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c :809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.1 /12274: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+ .}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/ 0x1e0 net/smc/smc_pnet.c:878 2 bloqueos retenidos por syz-executor.2/12280: #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, en: copy_net_ns+0x4c7/0x7b0 net /core/net_namespace.c:491 #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, en: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [en línea] #1: ffffffff8f375b88 (rtnl_mutex) {+.+.}-{3:3}, en: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878 • https://git.kernel.org/stable/c/bc4d1ebca11b4f194e262326bd45938e857c59d2 https://git.kernel.org/stable/c/b9117dc783c0ab0a3866812f70e07bf2ea071ac4 https://git.kernel.org/stable/c/d7ee3bf0caf599c14db0bf4af7aacd6206ef8a23 https://git.kernel.org/stable/c/a2e6bffc0388526ed10406040279a693d62b36ec https://git.kernel.org/stable/c/6e920422e7104928f760fc0e12b6d65ab097a2e7 https://git.kernel.org/stable/c/00af2aa93b76b1bade471ad0d0525d4d29ca5cc0 https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html •

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

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Fix null ptr deref in btintel_read_version If hci_cmd_sync_complete() is triggered and skb is NULL, then hdev->req_skb is NULL, which will cause this issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: btintel: corrija el ptr deref nulo en btintel_read_version Si se activa hci_cmd_sync_complete() y skb es NULL, entonces hdev->req_skb es NULL, lo que causará este problema. • https://git.kernel.org/stable/c/ec2049fb2b8be3e108fe2ef1f1040f91e72c9990 https://git.kernel.org/stable/c/68a69bb2ecafaacdb998a87783068fb51736f43b https://git.kernel.org/stable/c/86e9b47e8a75c74b1bd83a479979b425c5dc8bd9 https://git.kernel.org/stable/c/006936ecb4edfc3102464044f75858c714e34d28 https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912 https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/vc4: don't check if plane->state->fb == state->fb Currently, when using non-blocking commits, we can see the following kernel warning: [ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- This happens because, although `prepare_fb` and `cleanup_fb` are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The opposite can also be true. In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the `drm_atomic_get_new_plane_state()` helper function should be used. So, we could stick to this check, but using `drm_atomic_get_new_plane_state()`. But actually, this check is not re ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/vc4: no comprobar si plano->estado->fb == estado->fb Actualmente, al usar confirmaciones sin bloqueo, podemos ver la siguiente advertencia del kernel : [110.908514] ------------[ cortar aquí ]------------ [ 110.908529] refcount_t: subdesbordamiento; uso después de la liberación. [110.908620] ADVERTENCIA: CPU: 0 PID: 1866 en lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [110.908664] Módulos vinculados en: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes _arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm 2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) 2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks retroiluminación ip_tables x_tables ipv6 [110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Contaminado: GC 6.1.66 -v8+ #32 [110.909104] Nombre del hardware: Frambuesa Pi 3 Modelo B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one + 0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205 ] x26: 0000000000000002 x25: 00000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: [110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 00000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 00000000000000027 x9: c912d0d083728c00 [110.909359] x8: c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 00000000000000000 [ 110.909409] x2 : 00000000000 x1: ffffffc00913b750 x0: 0000000000000001 [110.909434] Rastreo de llamadas: [110.909441] refcount_dec_not_one+0xb8/0xc0 [110.909461] / 0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] 0/0x9dc [vc4] [110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [110.911397 ] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330 ] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/ 0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- Esto sucede porque, aunque `prepare_fb` y `cleanup_fb` están perfectamente equilibrados, no podemos garantizar la coherencia en el plano de verificación->estado ->fb == estado->fb. • https://git.kernel.org/stable/c/48bfb4b03c5ff6e1fa1dc73fb915e150b0968c40 https://git.kernel.org/stable/c/d6b2fe2db1d0927b2d7df5c763eba55d0e1def3c https://git.kernel.org/stable/c/5343f724c912c77541029123f47ecd3d2ea63bdd https://git.kernel.org/stable/c/5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9 •

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

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Skip do PCI error slot reset during RAS recovery Why: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. • https://git.kernel.org/stable/c/395ca1031acf89d8ecb26127c544a71688d96f35 https://git.kernel.org/stable/c/601429cca96b4af3be44172c3b64e4228515dbe1 https://access.redhat.com/security/cve/CVE-2024-35931 https://bugzilla.redhat.com/show_bug.cgi?id=2281523 •