Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb: fix memory leak in dvb_usb_adapter_init()<br /> <br /> Syzbot reports a memory leak in "dvb_usb_adapter_init()".<br /> The leak is due to not accounting for and freeing current iteration&amp;#39;s<br /> adapter-&gt;priv in case of an error. Currently if an error occurs,<br /> it will exit before incrementing "num_adapters_initalized",<br /> which is used as a reference counter to free all adap-&gt;priv<br /> in "dvb_usb_adapter_exit()". There are multiple error paths that<br /> can exit from before incrementing the counter. Including the<br /> error handling paths for "dvb_usb_adapter_stream_init()",<br /> "dvb_usb_adapter_dvb_init()" and "dvb_usb_adapter_frontend_init()"<br /> within "dvb_usb_adapter_init()".<br /> <br /> This means that in case of an error in any of these functions the<br /> current iteration is not accounted for and the current iteration&amp;#39;s<br /> adap-&gt;priv is not freed.<br /> <br /> Fix this by freeing the current iteration&amp;#39;s adap-&gt;priv in the<br /> "stream_init_err:" label in the error path. The rest of the<br /> (accounted for) adap-&gt;priv objects are freed in dvb_usb_adapter_exit()<br /> as expected using the num_adapters_initalized variable.<br /> <br /> Syzbot report:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8881172f1a00 (size 512):<br /> comm "kworker/0:2", pid 139, jiffies 4294994873 (age 10.960s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:75 [inline]<br /> [] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:184 [inline]<br /> [] dvb_usb_device_init.cold+0x4e5/0x79e drivers/media/usb/dvb-usb/dvb-usb-init.c:308<br /> [] dib0700_probe+0x8d/0x1b0 drivers/media/usb/dvb-usb/dib0700_core.c:883<br /> [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396<br /> [] call_driver_probe drivers/base/dd.c:542 [inline]<br /> [] really_probe.part.0+0xe7/0x310 drivers/base/dd.c:621<br /> [] really_probe drivers/base/dd.c:583 [inline]<br /> [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752<br /> [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:782<br /> [] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:899<br /> [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427<br /> [] __device_attach+0x122/0x260 drivers/base/dd.c:970<br /> [] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487<br /> [] device_add+0x5fb/0xdf0 drivers/base/core.c:3405<br /> [] usb_set_configuration+0x8f2/0xb80 drivers/usb/core/message.c:2170<br /> [] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238<br /> [] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293<br /> [] call_driver_probe drivers/base/dd.c:542 [inline]<br /> [] really_probe.part.0+0xe7/0x310 drivers/base/dd.c:621<br /> [] really_probe drivers/base/dd.c:583 [inline]<br /> [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix monitor mode bringup crash<br /> <br /> When the interface is brought up in monitor mode, it leads<br /> to NULL pointer dereference crash. This crash happens when<br /> the packet type is extracted for a SKB. This extraction<br /> which is present in the received msdu delivery path,is<br /> not needed for the monitor ring packets since they are<br /> all RAW packets. Hence appending the flags with<br /> "RX_FLAG_ONLY_MONITOR" to skip that extraction.<br /> <br /> Observed calltrace:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 0000000000000064<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048517000<br /> [0000000000000064] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> Modules linked in: ath11k_pci ath11k qmi_helpers<br /> CPU: 2 PID: 1781 Comm: napi/-271 Not tainted<br /> 6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6<br /> Hardware name: Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]<br /> lr : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k]<br /> sp : ffff80000ef5bb10<br /> x29: ffff80000ef5bb10 x28: 0000000000000000 x27: ffff000007baafa0<br /> x26: ffff000014a91ed0 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff800002b77378 x22: ffff000014a91ec0 x21: ffff000006c8d600<br /> x20: 0000000000000000 x19: ffff800002b77740 x18: 0000000000000006<br /> x17: 736564203634343a x16: 656e694c20657079 x15: 0000000000000143<br /> x14: 00000000ffffffea x13: ffff80000ef5b8b8 x12: ffff80000ef5b8c8<br /> x11: ffff80000a591d30 x10: ffff80000a579d40 x9 : c0000000ffffefff<br /> x8 : 0000000000000003 x7 : 0000000000017fe8 x6 : ffff80000a579ce8<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 3a35ec12ed7f8900 x1 : 0000000000000000 x0 : 0000000000000052<br /> Call trace:<br /> ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]<br /> ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k]<br /> ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k]<br /> ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k]<br /> ath11k_dp_service_srng+0x234/0x338 [ath11k]<br /> ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]<br /> __napi_poll+0x5c/0x190<br /> napi_threaded_poll+0xf0/0x118<br /> kthread+0xf4/0x110<br /> ret_from_fork+0x10/0x20<br /> <br /> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gud: Fix UBSAN warning<br /> <br /> UBSAN complains about invalid value for bool:<br /> <br /> [ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1<br /> [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device<br /> [ 101.213426] usbcore: registered new interface driver gud<br /> [ 101.989431] ================================================================================<br /> [ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9<br /> [ 101.989447] load of value 121 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> [ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3<br /> [ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018<br /> [ 101.989459] Workqueue: events_long gud_flush_work [gud]<br /> [ 101.989471] Call Trace:<br /> [ 101.989474] <br /> [ 101.989479] dump_stack_lvl+0x49/0x5f<br /> [ 101.989488] dump_stack+0x10/0x12<br /> [ 101.989493] ubsan_epilogue+0x9/0x3b<br /> [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49<br /> [ 101.989504] dma_buf_vmap.cold+0x38/0x3d<br /> [ 101.989511] ? find_busiest_group+0x48/0x300<br /> [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper]<br /> [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper]<br /> [ 101.989535] drm_gem_vmap+0x26/0x60 [drm]<br /> [ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper]<br /> [ 101.989630] gud_prep_flush+0xc1/0x710 [gud]<br /> [ 101.989639] ? _raw_spin_lock+0x17/0x40<br /> [ 101.989648] gud_flush_work+0x1e0/0x430 [gud]<br /> [ 101.989653] ? __switch_to+0x11d/0x470<br /> [ 101.989664] process_one_work+0x21f/0x3f0<br /> [ 101.989673] worker_thread+0x200/0x3e0<br /> [ 101.989679] ? rescuer_thread+0x390/0x390<br /> [ 101.989684] kthread+0xfd/0x130<br /> [ 101.989690] ? kthread_complete_and_exit+0x20/0x20<br /> [ 101.989696] ret_from_fork+0x22/0x30<br /> [ 101.989706] <br /> [ 101.989708] ================================================================================<br /> <br /> The source of this warning is in iosys_map_clear() called from<br /> dma_buf_vmap(). It conditionally sets values based on map-&gt;is_iomem. The<br /> iosys_map variables are allocated uninitialized on the stack leading to<br /> -&gt;is_iomem having all kinds of values and not only 0/1.<br /> <br /> Fix this by zeroing the iosys_map variables.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: pci_endpoint_test: Fix pci_endpoint_test_{copy,write,read}() panic<br /> <br /> The dma_map_single() doesn&amp;#39;t permit zero length mapping. It causes a follow<br /> panic.<br /> <br /> A panic was reported on arm64:<br /> <br /> [ 60.137988] ------------[ cut here ]------------<br /> [ 60.142630] kernel BUG at kernel/dma/swiotlb.c:624!<br /> [ 60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> [ 60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l<br /> 2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn<br /> c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl<br /> [ 60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237<br /> [ 60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)<br /> [ 60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590<br /> [ 60.213149] lr : swiotlb_map+0x88/0x1f0<br /> [ 60.216982] sp : ffff80000a883bc0<br /> [ 60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0<br /> [ 60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000<br /> [ 60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000<br /> [ 60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180<br /> [ 60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000<br /> [ 60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> [ 60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000<br /> [ 60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001<br /> [ 60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010<br /> [ 60.291658] Call trace:<br /> [ 60.294100] swiotlb_tbl_map_single+0x2c0/0x590<br /> [ 60.298629] swiotlb_map+0x88/0x1f0<br /> [ 60.302115] dma_map_page_attrs+0x188/0x230<br /> [ 60.306299] pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test]<br /> [ 60.312660] __arm64_sys_ioctl+0xa8/0xf0<br /> [ 60.316583] invoke_syscall+0x44/0x108<br /> [ 60.320334] el0_svc_common.constprop.0+0xcc/0xf0<br /> [ 60.325038] do_el0_svc+0x2c/0xb8<br /> [ 60.328351] el0_svc+0x2c/0x88<br /> [ 60.331406] el0t_64_sync_handler+0xb8/0xc0<br /> [ 60.335587] el0t_64_sync+0x18c/0x190<br /> [ 60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000)<br /> [ 60.345344] ---[ end trace 0000000000000000 ]---<br /> <br /> To fix it, this patch adds a checking the payload length if it is zero.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/uncore: Fix reference count leak in snr_uncore_mmio_map()<br /> <br /> pci_get_device() will increase the reference count for the returned<br /> pci_dev, so snr_uncore_get_mc_dev() will return a pci_dev with its<br /> reference count increased. We need to call pci_dev_put() to decrease the<br /> reference count. Let&amp;#39;s add the missing pci_dev_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: Use different devices for resource allocation and DT lookup<br /> <br /> Following by the below discussion, there&amp;#39;s the potential UAF issue<br /> between regulator and mfd.<br /> https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/<br /> <br /> From the analysis of Yingliang<br /> <br /> CPU A |CPU B<br /> mt6370_probe() |<br /> devm_mfd_add_devices() |<br /> |mt6370_regulator_probe()<br /> | regulator_register()<br /> | //allocate init_data and add it to devres<br /> | regulator_of_get_init_data()<br /> i2c_unregister_device() |<br /> device_del() |<br /> devres_release_all() |<br /> // init_data is freed |<br /> release_nodes() |<br /> | // using init_data causes UAF<br /> | regulator_register()<br /> <br /> It&amp;#39;s common to use mfd core to create child device for the regulator.<br /> In order to do the DT lookup for init data, the child that registered<br /> the regulator would pass its parent as the parameter. And this causes<br /> init data resource allocated to its parent, not itself. The issue happen<br /> when parent device is going to release and regulator core is still doing<br /> some operation of init data constraint for the regulator of child device.<br /> <br /> To fix it, this patch expand &amp;#39;regulator_register&amp;#39; API to use the<br /> different devices for init data allocation and DT lookup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/powerplay/psm: Fix memory leak in power state init<br /> <br /> Commit 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in power<br /> state init") made the power state init function return early in case of<br /> failure to get an entry from the powerplay table, but it missed to clean up<br /> the allocated memory for the current power state before returning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: meson-gx: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value,<br /> it will lead two issues:<br /> 1. The memory that allocated in mmc_alloc_host() is leaked.<br /> 2. In the remove() path, mmc_remove_host() will be called to<br /> delete device, but it&amp;#39;s not added yet, it will lead a kernel<br /> crash because of null-ptr-deref in device_del().<br /> <br /> Fix this by checking the return value and goto error path which<br /> will call mmc_free_host().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix memory leak in kfd_mem_dmamap_userptr()<br /> <br /> If the number of pages from the userptr BO differs from the SG BO then the<br /> allocated memory for the SG table doesn&amp;#39;t get freed before returning<br /> -EINVAL, which may lead to a memory leak in some error paths. Fix this by<br /> checking the number of pages before allocating memory for the SG table.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to invalidate dcc-&gt;f2fs_issue_discard in error path<br /> <br /> Syzbot reports a NULL pointer dereference issue as below:<br /> <br /> __refcount_add include/linux/refcount.h:193 [inline]<br /> __refcount_inc include/linux/refcount.h:250 [inline]<br /> refcount_inc include/linux/refcount.h:267 [inline]<br /> get_task_struct include/linux/sched/task.h:110 [inline]<br /> kthread_stop+0x34/0x1c0 kernel/kthread.c:703<br /> f2fs_stop_discard_thread+0x3c/0x5c fs/f2fs/segment.c:1638<br /> kill_f2fs_super+0x5c/0x194 fs/f2fs/super.c:4522<br /> deactivate_locked_super+0x70/0xe8 fs/super.c:332<br /> deactivate_super+0xd0/0xd4 fs/super.c:363<br /> cleanup_mnt+0x1f8/0x234 fs/namespace.c:1186<br /> __cleanup_mnt+0x20/0x30 fs/namespace.c:1193<br /> task_work_run+0xc4/0x14c kernel/task_work.c:177<br /> exit_task_work include/linux/task_work.h:38 [inline]<br /> do_exit+0x26c/0xbe0 kernel/exit.c:795<br /> do_group_exit+0x60/0xe8 kernel/exit.c:925<br /> __do_sys_exit_group kernel/exit.c:936 [inline]<br /> __se_sys_exit_group kernel/exit.c:934 [inline]<br /> __wake_up_parent+0x0/0x40 kernel/exit.c:934<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall arch/arm64/kernel/syscall.c:52 [inline]<br /> el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206<br /> el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636<br /> el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654<br /> el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581<br /> <br /> The root cause of this issue is in error path of f2fs_start_discard_thread(),<br /> it missed to invalidate dcc-&gt;f2fs_issue_discard, later kthread_stop() may<br /> access invalid pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid0, raid10: Don&amp;#39;t set discard sectors for request queue<br /> <br /> It should use disk_stack_limits to get a proper max_discard_sectors<br /> rather than setting a value by stack drivers.<br /> <br /> And there is a bug. If all member disks are rotational devices,<br /> raid0/raid10 set max_discard_sectors. So the member devices are<br /> not ssd/nvme, but raid0/raid10 export the wrong value. It reports<br /> warning messages in function __blkdev_issue_discard when mkfs.xfs<br /> like this:<br /> <br /> [ 4616.022599] ------------[ cut here ]------------<br /> [ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0<br /> [ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0<br /> [ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7<br /> [ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246<br /> [ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080<br /> [ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080<br /> [ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000<br /> [ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000<br /> [ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080<br /> [ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000<br /> [ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0<br /> [ 4616.236689] Call Trace:<br /> [ 4616.239428] blkdev_issue_discard+0x52/0xb0<br /> [ 4616.244108] blkdev_common_ioctl+0x43c/0xa00<br /> [ 4616.248883] blkdev_ioctl+0x116/0x280<br /> [ 4616.252977] __x64_sys_ioctl+0x8a/0xc0<br /> [ 4616.257163] do_syscall_64+0x5c/0x90<br /> [ 4616.261164] ? handle_mm_fault+0xc5/0x2a0<br /> [ 4616.265652] ? do_user_addr_fault+0x1d8/0x690<br /> [ 4616.270527] ? do_syscall_64+0x69/0x90<br /> [ 4616.274717] ? exc_page_fault+0x62/0x150<br /> [ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 4616.284748] RIP: 0033:0x7f9a55398c6b

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: Set fb_display[i]-&gt;mode to NULL when the mode is released<br /> <br /> Recently, we discovered the following issue through syzkaller:<br /> <br /> BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0<br /> Read of size 4 at addr ff11000001b3c69c by task syz.xxx<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xab/0xe0<br /> print_address_description.constprop.0+0x2c/0x390<br /> print_report+0xb9/0x280<br /> kasan_report+0xb8/0xf0<br /> fb_mode_is_equal+0x285/0x2f0<br /> fbcon_mode_deleted+0x129/0x180<br /> fb_set_var+0xe7f/0x11d0<br /> do_fb_ioctl+0x6a0/0x750<br /> fb_ioctl+0xe0/0x140<br /> __x64_sys_ioctl+0x193/0x210<br /> do_syscall_64+0x5f/0x9c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Based on experimentation and analysis, during framebuffer unregistration,<br /> only the memory of fb_info-&gt;modelist is freed, without setting the<br /> corresponding fb_display[i]-&gt;mode to NULL for the freed modes. This leads<br /> to UAF issues during subsequent accesses. Here&amp;#39;s an example of reproduction<br /> steps:<br /> 1. With /dev/fb0 already registered in the system, load a kernel module<br /> to register a new device /dev/fb1;<br /> 2. Set fb1&amp;#39;s mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);<br /> 3. Switch console from fb to VGA (to allow normal rmmod of the ko);<br /> 4. Unload the kernel module, at this point fb1&amp;#39;s modelist is freed, leaving<br /> a wild pointer in fb_display[];<br /> 5. Trigger the bug via system calls through fb0 attempting to delete a mode<br /> from fb0.<br /> <br /> Add a check in do_unregister_framebuffer(): if the mode to be freed exists<br /> in fb_display[], set the corresponding mode pointer to NULL.