CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47588 – sit: do not call ipip6_dev_free() from sit_init_net()
https://notcve.org/view.php?id=CVE-2021-47588
In the Linux kernel, the following vulnerability has been resolved: sit: do not call ipip6_dev_free() from sit_init_net() ipip6_dev_free is sit dev->priv_destructor, already called by register_netdevice() if something goes wrong. Alternative would be to make ipip6_dev_free() robust against multiple invocations, but other drivers do not implement this strategy. syzbot reported: dst_release underflow WARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173 Modules linked in: CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173 Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48 RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246 RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000 RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358 R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000 FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ipv6/sit.c:1414 [inline] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c:326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 kernel/fork.c:3075 __do_sys_unshare kernel/fork.c:3146 [inline] __se_sys_unshare kernel/fork.c:3144 [inline] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f66c882ce99 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200 RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000 </TASK> En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sit: no llame a ipip6_dev_free() desde sit_init_net() ipip6_dev_free es sit dev->priv_destructor, ya llamado por Register_netdevice() si algo sale mal. La alternativa sería hacer que ipip6_dev_free() sea robusto contra múltiples invocaciones, pero otros controladores no implementan esta estrategia. syzbot informó: dst_release underflow ADVERTENCIA: CPU: 0 PID: 5059 en net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173 Módulos vinculados en: CPU: 1 PID: 5059 Comm: syz -executor.4 Not tainted 5.16.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c :173 Código: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48 RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246 RAX: d6894a925dd15a00 RBX: RCX: 0000000000040000 RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000 RBP: 0000000000000000 R08 : ffffffff816a1f42 R09: ffffed1017344f2c R10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358 R13: 1ffffffff1bfd305 R14: ffffe8ffffcb135 8 R15: dffffc0000000000 FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 50033 CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ ipv6/sit.c:1414 [en línea] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c :326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 .c :3075 __do_sys_unshare kernel/fork.c:3146 [en línea] __se_sys_unshare kernel/fork.c:3144 [en línea] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [en línea ] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f66c882ce99 Código: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP:00 007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99 RDX: 0000000000000000 RSI: 0000000000 000000 RDI: 0000000048040200 RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000000 00246 R12: 0000000000000000 R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000 • https://git.kernel.org/stable/c/cf124db566e6b036b8bcbe8decbed740bdfac8c6 https://git.kernel.org/stable/c/95876855a55072572895a236b156ffb357fd5538 https://git.kernel.org/stable/c/4e1797914d8f223726ff6ae5ece4f97d73f21bab https://git.kernel.org/stable/c/e56b65c1e74d7f706d74b51baba15187be2fb4b5 https://git.kernel.org/stable/c/ad0ed314d6167b212939e3839428ba0c8bb16adb https://git.kernel.org/stable/c/6f46c59e60b64620d5d386c8ee2eaa11ebe3b595 https://git.kernel.org/stable/c/44a6c846bc3a7efe7d394bab8b2ae3b7f580e190 https://git.kernel.org/stable/c/e28587cc491ef0f3c51258fdc87fbc386 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47587 – net: systemport: Add global locking for descriptor lifecycle
https://notcve.org/view.php?id=CVE-2021-47587
In the Linux kernel, the following vulnerability has been resolved: net: systemport: Add global locking for descriptor lifecycle The descriptor list is a shared resource across all of the transmit queues, and the locking mechanism used today only protects concurrency across a given transmit queue between the transmit and reclaiming. This creates an opportunity for the SYSTEMPORT hardware to work on corrupted descriptors if we have multiple producers at once which is the case when using multiple transmit queues. This was particularly noticeable when using multiple flows/transmit queues and it showed up in interesting ways in that UDP packets would get a correct UDP header checksum being calculated over an incorrect packet length. Similarly TCP packets would get an equally correct checksum computed by the hardware over an incorrect packet length. The SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges when the driver produces a new descriptor anytime it writes to the WRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to re-organize its descriptors and it is possible that concurrent TX queues eventually break this internal allocation scheme to the point where the length/status part of the descriptor gets used for an incorrect data buffer. The fix is to impose a global serialization for all TX queues in the short section where we are writing to the WRITE_PORT_{HI,LO} registers which solves the corruption even with multiple concurrent TX queues being used. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: systemport: agregue bloqueo global para el ciclo de vida del descriptor. La lista de descriptores es un recurso compartido entre todas las colas de transmisión y el mecanismo de bloqueo que se usa hoy solo protege la concurrencia en una cola de transmisión determinada. entre la transmisión y la recuperación. • https://git.kernel.org/stable/c/80105befdb4b8cea924711b40b2462b87df65b62 https://git.kernel.org/stable/c/8ed2f5d08d6e59f8c78b2869bfb95d0be32c094c https://git.kernel.org/stable/c/de57f62f76450b934de8203711bdc4f7953c3421 https://git.kernel.org/stable/c/f3fde37d3f0d429f0fcce214cb52588a9e21260e https://git.kernel.org/stable/c/595a684fa6f23b21958379a18cfa83862c73c2e1 https://git.kernel.org/stable/c/c675256a7f131f5ba3f331efb715e8f31ea0e392 https://git.kernel.org/stable/c/6e1011cd183faae8daff275c72444edcdfe0d473 https://git.kernel.org/stable/c/eb4687c7442942e115420a30185f8d83f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47583 – media: mxl111sf: change mutex_init() location
https://notcve.org/view.php?id=CVE-2021-47583
In the Linux kernel, the following vulnerability has been resolved: media: mxl111sf: change mutex_init() location Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized mutex. The problem was in wrong mutex_init() location. Previous mutex_init(&state->msg_lock) call was in ->init() function, but dvb_usbv2_init() has this order of calls: dvb_usbv2_init() dvb_usbv2_adapter_init() dvb_usbv2_adapter_frontend_init() props->frontend_attach() props->init() Since mxl111sf_* devices call mxl111sf_ctrl_msg() in ->frontend_attach() internally we need to initialize state->msg_lock before frontend_attach(). To achieve it, ->probe() call added to all mxl111sf_* devices, which will simply initiaize mutex. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medio: mxl111sf: cambiar la ubicación de mutex_init() Syzbot informó que mxl111sf_ctrl_msg() usa un mutex no inicializado. El problema estaba en la ubicación mutex_init() incorrecta. • https://git.kernel.org/stable/c/8572211842afc53c8450fb470f2b8d02ba7592e0 https://git.kernel.org/stable/c/4b2d9600b31f9ba7adbc9f3c54a068615d27b390 https://git.kernel.org/stable/c/96f182c9f48b984447741f054ec301fdc8517035 https://git.kernel.org/stable/c/b99bdf127af91d53919e96292c05f737c45ea59a https://git.kernel.org/stable/c/8c6fdf62bfe1bc72bfceeaf832ef7499c7ed09ba https://git.kernel.org/stable/c/44870a9e7a3c24acbb3f888b2a7cc22c9bdf7e7f •
CVSS: 3.3EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47582 – USB: core: Make do_proc_control() and do_proc_bulk() killable
https://notcve.org/view.php?id=CVE-2021-47582
In the Linux kernel, the following vulnerability has been resolved: USB: core: Make do_proc_control() and do_proc_bulk() killable The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke usb_start_wait_urb(), which contains an uninterruptible wait with a user-specified timeout value. If timeout value is very large and the device being accessed does not respond in a reasonable amount of time, the kernel will complain about "Task X blocked for more than N seconds", as found in testing by syzbot: INFO: task syz-executor.0:8700 blocked for more than 143 seconds. Not tainted 5.14.0-rc7-syzkaller #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor.0 state:D stack:23192 pid: 8700 ppid: 8455 flags:0x00004004 Call Trace: context_switch kernel/sched/core.c:4681 [inline] __schedule+0xc07/0x11f0 kernel/sched/core.c:5938 schedule+0x14b/0x210 kernel/sched/core.c:6017 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85 __wait_for_common kernel/sched/completion.c:106 [inline] wait_for_common kernel/sched/completion.c:117 [inline] wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236 proc_bulk drivers/usb/core/devio.c:1273 [inline] usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline] usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713 ... To fix this problem, this patch replaces usbfs's calls to usb_control_msg() and usb_bulk_msg() with special-purpose code that does essentially the same thing (as recommended in the comment for usb_start_wait_urb()), except that it always uses a killable wait and it uses GFP_KERNEL rather than GFP_NOIO. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: core: Hacer que do_proc_control() y do_proc_bulk() se puedan eliminar. Los ioctls USBDEVFS_CONTROL y USBDEVFS_BULK invocan usb_start_wait_urb(), que contiene una espera ininterrumpida con un valor de tiempo de espera especificado por el usuario. Si el valor del tiempo de espera es muy grande y el dispositivo al que se accede no responde en un período de tiempo razonable, el kernel se quejará de "Tarea X bloqueada durante más de N segundos", como se encontró en las pruebas realizadas por syzbot: INFORMACIÓN: tarea syz-executor .0:8700 bloqueado durante más de 143 segundos. • https://git.kernel.org/stable/c/403716741c6c2c510dce44e88f085a740f535de6 https://git.kernel.org/stable/c/ae8709b296d80c7f45aa1f35c0e7659ad69edce1 https://access.redhat.com/security/cve/CVE-2021-47582 https://bugzilla.redhat.com/show_bug.cgi?id=2293247 • CWE-667: Improper Locking •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47580 – scsi: scsi_debug: Fix type in min_t to avoid stack OOB
https://notcve.org/view.php?id=CVE-2021-47580
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_debug: Fix type in min_t to avoid stack OOB Change min_t() to use type "u32" instead of type "int" to avoid stack out of bounds. With min_t() type "int" the values get sign extended and the larger value gets used causing stack out of bounds. BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:191 [inline] BUG: KASAN: stack-out-of-bounds in sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 Read of size 127 at addr ffff888072607128 by task syz-executor.7/18707 CPU: 1 PID: 18707 Comm: syz-executor.7 Not tainted 5.15.0-syzk #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [inline] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 drivers/scsi/scsi_debug.c:1162 fill_from_dev_buffer drivers/scsi/scsi_debug.c:1888 [inline] resp_readcap16+0x365/0x3b0 drivers/scsi/scsi_debug.c:1887 schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533 scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline] scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570/0x8c0 drivers/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 drivers/scsi/sg.c:939 sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: scsi_debug: corrige el tipo min_t para evitar la pila OOB. Cambie min_t() para usar el tipo "u32" en lugar de "int" para evitar la pila fuera de los límites. Con min_t() escriba "int", los valores se extienden y el valor mayor se usa provocando que la pila esté fuera de los límites. ERROR: KASAN: pila fuera de los límites en memcpy include/linux/fortify-string.h:191 [en línea] ERROR: KASAN: pila fuera de los límites en sg_copy_buffer+0x1de/0x240 lib/scatterlist.c: 976 Lectura del tamaño 127 en la dirección ffff888072607128 mediante la tarea syz-executor.7/18707 CPU: 1 PID: 18707 Comm: syz-executor.7 No contaminado 5.15.0-syzk #1 Nombre del hardware: Red Hat KVM, BIOS 1.13.0 -2 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106 print_address_description.constprop.9+0x28/0x160 mm/kasan/report.c:256 __kasan_report mm/kasan /report.c:442 [en línea] kasan_report.cold.14+0x7d/0x117 mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x1a3/0x210 mm/kasan/generic .c:189 memcpy+0x23/0x60 mm/kasan/shadow.c:65 memcpy include/linux/fortify-string.h:191 [en línea] sg_copy_buffer+0x1de/0x240 lib/scatterlist.c:976 sg_copy_from_buffer+0x33/0x40 lib/scatterlist.c:1000 fill_from_dev_buffer.part.34+0x82/0x130 controladores/scsi/scsi_debug.c:1162 fill_from_dev_buffer controladores/scsi/scsi_debug.c:1888 [en línea] resp_readcap16+0x365/0x3b0 controladores/scsi/scsi_debug.c :1887 Schedule_resp+0x4d8/0x1a70 controladores/scsi/scsi_debug.c:5478 scsi_debug_queuecommand+0x8c9/0x1ec0 controladores/scsi/scsi_debug.c:7533 controladores scsi_dispatch_cmd/scsi/scsi_lib.c:1520 [en línea] Controladores 0x16b0/0x2d40/ scsi/scsi_lib.c:1699 blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639 __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325 blk_mq_sched_dispatch_requests+0x10 5/0x190 cuadra/blk-mq-programado. c:358 __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761 __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838 blk_mq_run_hw_queue+0x18d/0x350 :1891 blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474 blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62 sg_common_write.isra.18+0xeb3/0x2000 drivers/scsi/sg.c:836 sg_new_write.isra.19+0x570 /0x8c0 controladores/scsi/sg.c:774 sg_ioctl_common+0x14d6/0x2710 controladores/scsi/sg.c:939 sg_ioctl+0xa2/0x180 controladores/scsi/sg.c:1165 vfs_ioctl fs/ioctl.c:51 [en línea] __do_sys_ioctl fs/ioctl.c:874 [en línea] __se_sys_ioctl fs/ioctl.c:860 [en línea] __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] llamada al sistema_64 +0x3a/0x80 arch/x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae • https://git.kernel.org/stable/c/bdb854f134b964528fa543e0351022eb45bd7346 https://git.kernel.org/stable/c/3085147645938eb41f0bc0e25ef9791e71f5ee4b https://git.kernel.org/stable/c/36e07d7ede88a1f1ef8f0f209af5b7612324ac2c •