CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52617 – PCI: switchtec: Fix stdev_release() crash after surprise hot remove
https://notcve.org/view.php?id=CVE-2023-52617
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). • https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355 https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8 https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3 https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693 https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66 https://lists.debian.org/debian-lts-announce/2024/06/ •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26638 – nbd: always initialize struct msghdr completely
https://notcve.org/view.php?id=CVE-2024-26638
In the Linux kernel, the following vulnerability has been resolved: nbd: always initialize struct msghdr completely syzbot complains that msg->msg_get_inq value can be uninitialized [1] struct msghdr got many new fields recently, we should always make sure their values is zero by default. [1] BUG: KMSAN: uninit-value in tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 inet_recvmsg+0x131/0x580 net/ipv4/af_inet.c:879 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x12b/0x1e0 net/socket.c:1066 __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700 worker_thread+0xf45/0x1490 kernel/workqueue.c:2781 kthread+0x3ed/0x540 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Local variable msg created at: __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513 nbd_read_reply drivers/block/nbd.c:732 [inline] recv_work+0x262/0x3100 drivers/block/nbd.c:863 CPU: 1 PID: 7465 Comm: kworker/u5:1 Not tainted 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: nbd5-recv recv_work En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nbd: siempre inicializa completamente la estructura msghdr syzbot se queja de que el valor msg->msg_get_inq puede no estar inicializado [1] la estructura msghdr obtuvo muchos campos nuevos recientemente, siempre debemos asegurarnos de que sus valores sean cero por defecto. [1] ERROR: KMSAN: valor uninit en tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571 inet_recvmsg+0x131/0x580 net/ipv4/af_inet. c:879 sock_recvmsg_nosec net/socket.c:1044 [en línea] sock_recvmsg+0x12b/0x1e0 net/socket.c:1066 __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538 nbd_read_reply drivers/block/nbd.c:732 [en línea] recv_work+0x262/0x3100 drivers/block/nbd.c:863 Process_one_work kernel/workqueue.c:2627 [en línea] Process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700 workqueue.c :2781 kthread+0x3ed/0x540 kernel/kthread.c:388 ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Mensaje de variable local creado en: __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513 nbd_read_reply drivers/block/nbd.c:732 [en línea] recv_work+0x262/0x3100 drivers/block/nbd.c:863 CPU: 1 PID: 7465 Comm : kworker/u5:1 No contaminado 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 Cola de trabajo: nbd5-recv recv_work • https://git.kernel.org/stable/c/f94fd25cb0aaf77fd7453f31c5d394a1a68ecf60 https://git.kernel.org/stable/c/d9c54763e5cdbbd3f81868597fe8aca3c96e6387 https://git.kernel.org/stable/c/1960f2b534da1e6c65fb96f9e98bda773495f406 https://git.kernel.org/stable/c/b0028f333420a65a53a63978522db680b37379dd https://git.kernel.org/stable/c/78fbb92af27d0982634116c7a31065f24d092826 https://access.redhat.com/security/cve/CVE-2024-26638 https://bugzilla.redhat.com/show_bug.cgi?id=2270103 • CWE-456: Missing Initialization of a Variable •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-26637 – wifi: ath11k: rely on mac80211 debugfs handling for vif
https://notcve.org/view.php?id=CVE-2024-26637
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: rely on mac80211 debugfs handling for vif mac80211 started to delete debugfs entries in certain cases, causing a ath11k to crash when it tried to delete the entries later. Fix this by relying on mac80211 to delete the entries when appropriate and adding them from the vif_add_debugfs handler. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath11k: confía en el manejo de debugfs de mac80211 para vif mac80211 comenzó a eliminar entradas de debugfs en ciertos casos, lo que provocó que ath11k fallara cuando intentó eliminar las entradas más tarde. Solucione este problema confiando en mac80211 para eliminar las entradas cuando corresponda y agregándolas desde el controlador vif_add_debugfs. • https://git.kernel.org/stable/c/0a3d898ee9a8303d5b3982b97ef0703919c3ea76 https://git.kernel.org/stable/c/aa74ce30a8a40d19a4256de4ae5322e71344a274 https://git.kernel.org/stable/c/556857aa1d0855aba02b1c63bc52b91ec63fc2cc •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26636 – llc: make llc_ui_sendmsg() more robust against bonding changes
https://notcve.org/view.php?id=CVE-2024-26636
In the Linux kernel, the following vulnerability has been resolved: llc: make llc_ui_sendmsg() more robust against bonding changes syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1] Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed. This fix: - Uses LL_RESERVED_SPACE() to reserve space. - Check all conditions again after socket lock is held again. - Do not account Ethernet header for mtu limitation. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: hacer que llc_ui_sendmsg() sea más robusto contra cambios de vinculación syzbot pudo engañar a llc_ui_sendmsg(), asignando un skb sin espacio libre, pero posteriormente intentó enviar 14 bytes de encabezado Ethernet [ 1] Como otros, llc_ui_sendmsg() libera el bloqueo del socket antes de llamar a sock_alloc_send_skb(). Luego lo adquiere nuevamente, pero no rehace todas las comprobaciones de cordura que se realizaron. Esta solución: - Utiliza LL_RESERVED_SPACE() para reservar espacio. - Verifique todas las condiciones nuevamente después de mantener nuevamente el bloqueo del casquillo. - No tenga en cuenta el encabezado Ethernet para la limitación de mtu. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 ERROR del kernel en net/core/skbuff.c:193. Error interno: Ups - ERROR: 00000000f2000800 [#1] PREEMPT Módulos SMP vinculados en: CPU: 0 PID: 6875 Comm: syz-executor.0 No contaminado 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Nombre del hardware : Google Google Compute Engine/Google Compute Engine, BIOS Google 17/11/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc: skb_panic net/core/skbuff.c:189 [en línea] pc: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr: skb_panic net/core/skbuff.c:189 [en línea] lr: skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp: ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c 9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x1 7: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9: e28a51f1087e8400 x8: e28a 51f1087e8400 x7: ffff80008028f8d0 x6: 0000000000000000 x5: 0000000000000001 x4: 0000000000000001 x3: ffff800082b78714 x2: 00000000000000 001 x1: 0000000100000000 x0: 0000000000000089 Rastreo de llamadas: skb_panic net/core /skbuff.c:189 [en línea] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c: 83 dev_hard_header include/linux/netdevice.h:3188 [en línea] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_ acciones net/llc/llc_sap.c :153 [en línea] llc_sap_next_state net/llc/llc_sap.c:182 [en línea] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ ui_sendmsg+0x7bc/ 0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs /splice.c:881 do_splice_from fs/splice.c:933 [en línea] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice. c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [en línea] __se_sys_sendfile64 fs/read_write.c:1308 [en línea] __arm64_sys_sendfile64+0x160/0x3b4 fs /read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [en línea] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/ 0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+ 0x190/0x194 arch/arm64/kernel/entry.S:595 Código: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249 https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4 https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565f •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26635 – llc: Drop support for ETH_P_TR_802_2.
https://notcve.org/view.php?id=CVE-2024-26635
In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring"). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let's remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: llc: Eliminación del soporte para ETH_P_TR_802_2. syzbot informó un error de valor uninit a continuación. [0] llc admite ETH_P_802_2 (0x0004) y solía admitir ETH_P_TR_802_2 (0x0011), y syzbot abusó de este último para desencadenar el error. escribir$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd" }}}}, 0x16) llc_conn_handler() inicializa las variables locales {saddr,daddr}.mac basadas en skb en llc_pdu_decode_sa()/llc_pdu_decode_da() y las pasa a __llc_lookup(). Sin embargo, la inicialización se realiza solo cuando skb->protocol es htons(ETH_P_802_2); de lo contrario, __llc_lookup_establecido() y __llc_lookup_listener() leerán basura. La inicialización faltante existía antes de el commit 211ed865108e ("net: eliminar todas las instancias de procesamiento especial para Token Ring"). Quitó la parte para expulsar el token ring, pero se olvidó de cerrar la puerta permitiendo que los paquetes ETH_P_TR_802_2 se colaran en llc_rcv(). Eliminemos llc_tr_packet_type y completemos la desaprobación. [0]: ERROR: KMSAN: valor uninit en __llc_lookup_establecido+0xe9d/0xf90 __llc_lookup_establecido+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [en línea] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:79 1 llc_rcv +0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [en línea] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [en línea] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [en línea] new_sync_write fs/read_write.c:491 [en línea] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [en línea] __se_sys_write fs/read_write.c:646 [en línea] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common. c: 51 [en línea] do_syscall_64+0x44/0x110 arch/x86/entry/comunes.c: 82 entry_syscall_64_after_hwframe+0x63/0x6b local variable daddr creado FBB /0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 No contaminado 6.6.0-syzkaller-14500-g1c41041124bd #0 Nombre de hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10 /09/2023 • https://git.kernel.org/stable/c/211ed865108e24697b44bee5daac502ee6bdd4a4 https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62 https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097 https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828 https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6 https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8 https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a •