CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35936 – btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
https://notcve.org/view.php?id=CVE-2024-35936
In the Linux kernel, the following vulnerability has been resolved: btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption, as it could be caused only by two impossible conditions: - at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1 - after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: maneja el error de búsqueda del árbol de fragmentos en btrfs_relocate_sys_chunks() El caso no controlado en el bucle btrfs_relocate_sys_chunks() es una corrupción, ya que solo podría ser causado por dos condiciones imposibles: - al principio el La clave de búsqueda está configurada para buscar un elemento del árbol de fragmentos, con desplazamiento -1, esta es una búsqueda inexacta y la clave->desplazamiento contendrá el desplazamiento correcto tras una búsqueda exitosa, un elemento de árbol de fragmentos válido no puede tener un desplazamiento -1 - después de la primera búsqueda exitosa, found_key corresponde a un elemento fragmentado, el desplazamiento se reduce en 1 antes del siguiente ciclo, es imposible encontrar un elemento fragmentado allí debido a restricciones de alineación y tamaño • https://git.kernel.org/stable/c/bebd9e0ff90034875c5dfe4bd514fd7055fc7a89 https://git.kernel.org/stable/c/576164bd01bd795f8b09fb194b493103506b33c9 https://git.kernel.org/stable/c/87299cdaae757f3f41212146cfb5b3af416b8385 https://git.kernel.org/stable/c/d1ffa4ae2d591fdd40471074e79954ec45f147f7 https://git.kernel.org/stable/c/36c2a2863bc3896243eb724dc3fd4cf9aea633f2 https://git.kernel.org/stable/c/0d23b34c68c46cd225b55868bc8a269e3134816d https://git.kernel.org/stable/c/1f9212cdbd005bc55f2b7422e7b560d9c02bd1da https://git.kernel.org/stable/c/7411055db5ce64f836aaffd422396af00 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-35935 – btrfs: send: handle path ref underflow in header iterate_inode_ref()
https://notcve.org/view.php?id=CVE-2024-35935
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: 0CVE-2024-35934 – net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()
https://notcve.org/view.php?id=CVE-2024-35934
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: 0CVE-2024-35933 – Bluetooth: btintel: Fix null ptr deref in btintel_read_version
https://notcve.org/view.php?id=CVE-2024-35933
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: 0CVE-2024-35932 – drm/vc4: don't check if plane->state->fb == state->fb
https://notcve.org/view.php?id=CVE-2024-35932
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 •