Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sunplus: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value,<br /> 1. the memory allocated in mmc_alloc_host() will be leaked<br /> 2. null-ptr-deref will happen when calling mmc_remove_host()<br /> in remove function spmmc_drv_remove() because deleting not<br /> added device.<br /> <br /> Fix this by checking the return value of mmc_add_host(). Moreover,<br /> I fixed the error handling path of spmmc_drv_probe() to clean up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: stm32: Fix refcount leak in stm32_pctrl_get_irq_domain<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: flower: fix filter idr initialization<br /> <br /> The cited commit moved idr initialization too early in fl_change() which<br /> allows concurrent users to access the filter that is still being<br /> initialized and is in inconsistent state, which, in turn, can cause NULL<br /> pointer dereference [0]. Since there is no obvious way to fix the ordering<br /> without reverting the whole cited commit, alternative approach taken to<br /> first insert NULL pointer into idr in order to allocate the handle but<br /> still cause fl_get() to return NULL and prevent concurrent users from<br /> seeing the filter while providing miss-to-action infrastructure with valid<br /> handle id early in fl_change().<br /> <br /> [ 152.434728] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN<br /> [ 152.436163] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> [ 152.437269] CPU: 4 PID: 3877 Comm: tc Not tainted 6.3.0-rc4+ #5<br /> [ 152.438110] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 152.439644] RIP: 0010:fl_dump_key+0x8b/0x1d10 [cls_flower]<br /> [ 152.440461] Code: 01 f2 02 f2 c7 40 08 04 f2 04 f2 c7 40 0c 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 00 01 00 00 48 89 c8 48 c1 e8 03 b6 04 10 84 c0 74 08 3c 03 0f 8e 98 19 00 00 8b 13 85 d2 74 57<br /> [ 152.442885] RSP: 0018:ffff88817a28f158 EFLAGS: 00010246<br /> [ 152.443851] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> [ 152.444826] RDX: dffffc0000000000 RSI: ffffffff8500ae80 RDI: ffff88810a987900<br /> [ 152.445791] RBP: ffff888179d88240 R08: ffff888179d8845c R09: ffff888179d88240<br /> [ 152.446780] R10: ffffed102f451e48 R11: 00000000fffffff2 R12: ffff88810a987900<br /> [ 152.447741] R13: ffffffff8500ae80 R14: ffff88810a987900 R15: ffff888149b3c738<br /> [ 152.448756] FS: 00007f5eb2a34800(0000) GS:ffff88881ec00000(0000) knlGS:0000000000000000<br /> [ 152.449888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 152.450685] CR2: 000000000046ad19 CR3: 000000010b0bd006 CR4: 0000000000370ea0<br /> [ 152.451641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 152.452628] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 152.453588] Call Trace:<br /> [ 152.454032] <br /> [ 152.454447] ? netlink_sendmsg+0x7a1/0xcb0<br /> [ 152.455109] ? sock_sendmsg+0xc5/0x190<br /> [ 152.455689] ? ____sys_sendmsg+0x535/0x6b0<br /> [ 152.456320] ? ___sys_sendmsg+0xeb/0x170<br /> [ 152.456916] ? do_syscall_64+0x3d/0x90<br /> [ 152.457529] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 152.458321] ? ___sys_sendmsg+0xeb/0x170<br /> [ 152.458958] ? __sys_sendmsg+0xb5/0x140<br /> [ 152.459564] ? do_syscall_64+0x3d/0x90<br /> [ 152.460122] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 152.460852] ? fl_dump_key_options.part.0+0xea0/0xea0 [cls_flower]<br /> [ 152.461710] ? _raw_spin_lock+0x7a/0xd0<br /> [ 152.462299] ? _raw_read_lock_irq+0x30/0x30<br /> [ 152.462924] ? nla_put+0x15e/0x1c0<br /> [ 152.463480] fl_dump+0x228/0x650 [cls_flower]<br /> [ 152.464112] ? fl_tmplt_dump+0x210/0x210 [cls_flower]<br /> [ 152.464854] ? __kmem_cache_alloc_node+0x1a7/0x330<br /> [ 152.465592] ? nla_put+0x15e/0x1c0<br /> [ 152.466160] tcf_fill_node+0x515/0x9a0<br /> [ 152.466766] ? tc_setup_offload_action+0xf0/0xf0<br /> [ 152.467463] ? __alloc_skb+0x13c/0x2a0<br /> [ 152.468067] ? __build_skb_around+0x330/0x330<br /> [ 152.468814] ? fl_get+0x107/0x1a0 [cls_flower]<br /> [ 152.469503] tc_del_tfilter+0x718/0x1330<br /> [ 152.470115] ? is_bpf_text_address+0xa/0x20<br /> [ 152.470765] ? tc_ctl_chain+0xee0/0xee0<br /> [ 152.471335] ? __kernel_text_address+0xe/0x30<br /> [ 152.471948] ? unwind_get_return_address+0x56/0xa0<br /> [ 152.472639] ? __thaw_task+0x150/0x150<br /> [ 152.473218] ? arch_stack_walk+0x98/0xf0<br /> [ 152.473839] ? __stack_depot_save+0x35/0x4c0<br /> [ 152.474501] ? stack_trace_save+0x91/0xc0<br /> [ 152.475119] ? security_capable+0x51/0x90<br /> [ 152.475741] rtnetlink_rcv_msg+0x2c1/0x9d0<br /> [ 152.476387] ? rtnl_calcit.isra.0+0x2b0/0x2b0<br /> [ 152.477042]<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: uclogic: Correct devm device reference for hidinput input_dev name<br /> <br /> Reference the HID device rather than the input device for the devm<br /> allocation of the input_dev name. Referencing the input_dev would lead to a<br /> use-after-free when the input_dev was unregistered and subsequently fires a<br /> uevent that depends on the name. At the point of firing the uevent, the<br /> name would be freed by devres management.<br /> <br /> Use devm_kasprintf to simplify the logic for allocating memory and<br /> formatting the input_dev name string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ov5675: Fix memleak in ov5675_init_controls()<br /> <br /> There is a kmemleak when testing the media/i2c/ov5675.c with bpf mock<br /> device:<br /> <br /> AssertionError: unreferenced object 0xffff888107362160 (size 16):<br /> comm "python3", pid 277, jiffies 4294832798 (age 20.722s)<br /> hex dump (first 16 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc_node+0x44/0x1b0<br /> [] kvmalloc_node+0x34/0x180<br /> [] v4l2_ctrl_handler_init_class+0x11d/0x180<br /> [videodev]<br /> [] ov5675_probe+0x38b/0x897 [ov5675]<br /> [] i2c_device_probe+0x28d/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x386/0x540<br /> [] of_i2c_register_device+0xf1/0x110<br /> [] of_i2c_notify+0xfc/0x1f0<br /> <br /> ov5675_init_controls() won&amp;#39;t clean all the allocated resources in fail<br /> path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to<br /> prevent memleak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: fix memory leak in mt7996_mcu_exit<br /> <br /> Always purge mcu skb queues in mt7996_mcu_exit routine even if<br /> mt7996_firmware_state fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix null pointer panic in tracepoint in __replace_atomic_write_block<br /> <br /> We got a kernel panic if old_addr is NULL.<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=217266<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> Call Trace:<br /> <br /> f2fs_commit_atomic_write+0x619/0x990 [f2fs a1b985b80f5babd6f3ea778384908880812bfa43]<br /> __f2fs_ioctl+0xd8e/0x4080 [f2fs a1b985b80f5babd6f3ea778384908880812bfa43]<br /> ? vfs_write+0x2ae/0x3f0<br /> ? vfs_write+0x2ae/0x3f0<br /> __x64_sys_ioctl+0x91/0xd0<br /> do_syscall_64+0x5c/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7f69095fe53f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_api: remove block_cb from driver_list before freeing<br /> <br /> Error handler of tcf_block_bind() frees the whole bo-&gt;cb_list on error.<br /> However, by that time the flow_block_cb instances are already in the driver<br /> list because driver ndo_setup_tc() callback is called before that up the<br /> call chain in tcf_block_offload_cmd(). This leaves dangling pointers to<br /> freed objects in the list and causes use-after-free[0]. Fix it by also<br /> removing flow_block_cb instances from driver_list before deallocating them.<br /> <br /> [0]:<br /> [ 279.868433] ==================================================================<br /> [ 279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963<br /> <br /> [ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4<br /> [ 279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 279.876295] Call Trace:<br /> [ 279.876882] <br /> [ 279.877413] dump_stack_lvl+0x33/0x50<br /> [ 279.878198] print_report+0xc2/0x610<br /> [ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.879994] kasan_report+0xae/0xe0<br /> [ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.881744] ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core]<br /> [ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0<br /> [ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0<br /> [ 279.885037] ? tcf_block_setup+0x6b0/0x6b0<br /> [ 279.885901] ? mutex_lock+0x7d/0xd0<br /> [ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0<br /> [ 279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress]<br /> [ 279.888846] tcf_block_get_ext+0x61c/0x1200<br /> [ 279.889711] ingress_init+0x112/0x1c0 [sch_ingress]<br /> [ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress]<br /> [ 279.891701] qdisc_create+0x401/0xea0<br /> [ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470<br /> [ 279.893473] tc_modify_qdisc+0x6f7/0x16d0<br /> [ 279.894344] ? tc_get_qdisc+0xac0/0xac0<br /> [ 279.895213] ? mutex_lock+0x7d/0xd0<br /> [ 279.896005] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0<br /> [ 279.897770] ? rtnl_calcit.isra.0+0x2b0/0x2b0<br /> [ 279.898672] ? __sys_sendmsg+0xb5/0x140<br /> [ 279.899494] ? do_syscall_64+0x3d/0x90<br /> [ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 279.901337] ? kasan_save_stack+0x2e/0x40<br /> [ 279.902177] ? kasan_save_stack+0x1e/0x40<br /> [ 279.903058] ? kasan_set_track+0x21/0x30<br /> [ 279.903913] ? kasan_save_free_info+0x2a/0x40<br /> [ 279.904836] ? ____kasan_slab_free+0x11a/0x1b0<br /> [ 279.905741] ? kmem_cache_free+0x179/0x400<br /> [ 279.906599] netlink_rcv_skb+0x12c/0x360<br /> [ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0<br /> [ 279.908360] ? netlink_ack+0x1550/0x1550<br /> [ 279.909192] ? rhashtable_walk_peek+0x170/0x170<br /> [ 279.910135] ? kmem_cache_alloc_node+0x1af/0x390<br /> [ 279.911086] ? _copy_from_iter+0x3d6/0xc70<br /> [ 279.912031] netlink_unicast+0x553/0x790<br /> [ 279.912864] ? netlink_attachskb+0x6a0/0x6a0<br /> [ 279.913763] ? netlink_recvmsg+0x416/0xb50<br /> [ 279.914627] netlink_sendmsg+0x7a1/0xcb0<br /> [ 279.915473] ? netlink_unicast+0x790/0x790<br /> [ 279.916334] ? iovec_from_user.part.0+0x4d/0x220<br /> [ 279.917293] ? netlink_unicast+0x790/0x790<br /> [ 279.918159] sock_sendmsg+0xc5/0x190<br /> [ 279.918938] ____sys_sendmsg+0x535/0x6b0<br /> [ 279.919813] ? import_iovec+0x7/0x10<br /> [ 279.920601] ? kernel_sendmsg+0x30/0x30<br /> [ 279.921423] ? __copy_msghdr+0x3c0/0x3c0<br /> [ 279.922254] ? import_iovec+0x7/0x10<br /> [ 279.923041] ___sys_sendmsg+0xeb/0x170<br /> [ 279.923854] ? copy_msghdr_from_user+0x110/0x110<br /> [ 279.924797] ? ___sys_recvmsg+0xd9/0x130<br /> [ 279.925630] ? __perf_event_task_sched_in+0x183/0x470<br /> [ 279.926656] ? ___sys_sendmsg+0x170/0x170<br /> [ 279.927529] ? ctx_sched_in+0x530/0x530<br /> [ 279.928369] ? update_curr+0x283/0x4f0<br /> [ 279.929185] ? perf_event_update_userpage+0x570/0x570<br /> [ 279.930201] ? __fget_light+0x57/0x520<br /> [ 279.931023] ? __switch_to+0x53d/0xe70<br /> [ 27<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfree<br /> <br /> The call stack shown below is a scenario in the Linux 4.19 kernel.<br /> Allocating memory failed where exfat fs use kmalloc_array due to<br /> system memory fragmentation, while the u-disk was inserted without<br /> recognition.<br /> Devices such as u-disk using the exfat file system are pluggable and<br /> may be insert into the system at any time.<br /> However, long-term running systems cannot guarantee the continuity of<br /> physical memory. Therefore, it&amp;#39;s necessary to address this issue.<br /> <br /> Binder:2632_6: page allocation failure: order:4,<br /> mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)<br /> Call trace:<br /> [242178.097582] dump_backtrace+0x0/0x4<br /> [242178.097589] dump_stack+0xf4/0x134<br /> [242178.097598] warn_alloc+0xd8/0x144<br /> [242178.097603] __alloc_pages_nodemask+0x1364/0x1384<br /> [242178.097608] kmalloc_order+0x2c/0x510<br /> [242178.097612] kmalloc_order_trace+0x40/0x16c<br /> [242178.097618] __kmalloc+0x360/0x408<br /> [242178.097624] load_alloc_bitmap+0x160/0x284<br /> [242178.097628] exfat_fill_super+0xa3c/0xe7c<br /> [242178.097635] mount_bdev+0x2e8/0x3a0<br /> [242178.097638] exfat_fs_mount+0x40/0x50<br /> [242178.097643] mount_fs+0x138/0x2e8<br /> [242178.097649] vfs_kern_mount+0x90/0x270<br /> [242178.097655] do_mount+0x798/0x173c<br /> [242178.097659] ksys_mount+0x114/0x1ac<br /> [242178.097665] __arm64_sys_mount+0x24/0x34<br /> [242178.097671] el0_svc_common+0xb8/0x1b8<br /> [242178.097676] el0_svc_handler+0x74/0x90<br /> [242178.097681] el0_svc+0x8/0x340<br /> <br /> By analyzing the exfat code,we found that continuous physical memory<br /> is not required here,so kvmalloc_array is used can solve this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: Fix timeout of a call that hasn&amp;#39;t yet been granted a channel<br /> <br /> afs_make_call() calls rxrpc_kernel_begin_call() to begin a call (which may<br /> get stalled in the background waiting for a connection to become<br /> available); it then calls rxrpc_kernel_set_max_life() to set the timeouts -<br /> but that starts the call timer so the call timer might then expire before<br /> we get a connection assigned - leading to the following oops if the call<br /> stalled:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> CPU: 1 PID: 5111 Comm: krxrpcio/0 Not tainted 6.3.0-rc7-build3+ #701<br /> RIP: 0010:rxrpc_alloc_txbuf+0xc0/0x157<br /> ...<br /> Call Trace:<br /> <br /> rxrpc_send_ACK+0x50/0x13b<br /> rxrpc_input_call_event+0x16a/0x67d<br /> rxrpc_io_thread+0x1b6/0x45f<br /> ? _raw_spin_unlock_irqrestore+0x1f/0x35<br /> ? rxrpc_input_packet+0x519/0x519<br /> kthread+0xe7/0xef<br /> ? kthread_complete_and_exit+0x1b/0x1b<br /> ret_from_fork+0x22/0x30<br /> <br /> Fix this by noting the timeouts in struct rxrpc_call when the call is<br /> created. The timer will be started when the first packet is transmitted.<br /> <br /> It shouldn&amp;#39;t be possible to trigger this directly from userspace through<br /> AF_RXRPC as sendmsg() will return EBUSY if the call is in the<br /> waiting-for-conn state if it dropped out of the wait due to a signal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix NULL pointer dereference in &amp;#39;ni_write_inode&amp;#39;<br /> <br /> Syzbot found the following issue:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000016<br /> Mem abort info:<br /> ESR = 0x0000000096000006<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x06: level 2 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000006<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af56000<br /> [0000000000000016] pgd=08000001090da003, p4d=08000001090da003, pud=08000001090ce003, pmd=0000000000000000<br /> Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 1 PID: 3036 Comm: syz-executor206 Not tainted 6.0.0-rc6-syzkaller-17739-g16c9f284e746 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : is_rec_inuse fs/ntfs3/ntfs.h:313 [inline]<br /> pc : ni_write_inode+0xac/0x798 fs/ntfs3/frecord.c:3232<br /> lr : ni_write_inode+0xa0/0x798 fs/ntfs3/frecord.c:3226<br /> sp : ffff8000126c3800<br /> x29: ffff8000126c3860 x28: 0000000000000000 x27: ffff0000c8b02000<br /> x26: ffff0000c7502320 x25: ffff0000c7502288 x24: 0000000000000000<br /> x23: ffff80000cbec91c x22: ffff0000c8b03000 x21: ffff0000c8b02000<br /> x20: 0000000000000001 x19: ffff0000c75024d8 x18: 00000000000000c0<br /> x17: ffff80000dd1b198 x16: ffff80000db59158 x15: ffff0000c4b6b500<br /> x14: 00000000000000b8 x13: 0000000000000000 x12: ffff0000c4b6b500<br /> x11: ff80800008be1b60 x10: 0000000000000000 x9 : ffff0000c4b6b500<br /> x8 : 0000000000000000 x7 : ffff800008be1b50 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000<br /> x2 : 0000000000000008 x1 : 0000000000000001 x0 : 0000000000000000<br /> Call trace:<br /> is_rec_inuse fs/ntfs3/ntfs.h:313 [inline]<br /> ni_write_inode+0xac/0x798 fs/ntfs3/frecord.c:3232<br /> ntfs_evict_inode+0x54/0x84 fs/ntfs3/inode.c:1744<br /> evict+0xec/0x334 fs/inode.c:665<br /> iput_final fs/inode.c:1748 [inline]<br /> iput+0x2c4/0x324 fs/inode.c:1774<br /> ntfs_new_inode+0x7c/0xe0 fs/ntfs3/fsntfs.c:1660<br /> ntfs_create_inode+0x20c/0xe78 fs/ntfs3/inode.c:1278<br /> ntfs_create+0x54/0x74 fs/ntfs3/namei.c:100<br /> lookup_open fs/namei.c:3413 [inline]<br /> open_last_lookups fs/namei.c:3481 [inline]<br /> path_openat+0x804/0x11c4 fs/namei.c:3688<br /> do_filp_open+0xdc/0x1b8 fs/namei.c:3718<br /> do_sys_openat2+0xb8/0x22c fs/open.c:1311<br /> do_sys_open fs/open.c:1327 [inline]<br /> __do_sys_openat fs/open.c:1343 [inline]<br /> __se_sys_openat fs/open.c:1338 [inline]<br /> __arm64_sys_openat+0xb0/0xe0 fs/open.c:1338<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<br /> Code: 97dafee4 340001b4 f9401328 2a1f03e0 (79402d14)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Above issue may happens as follows:<br /> ntfs_new_inode<br /> mi_init<br /> mi-&gt;mrec = kmalloc(sbi-&gt;record_size, GFP_NOFS); --&gt;failed to allocate memory<br /> if (!mi-&gt;mrec)<br /> return -ENOMEM;<br /> iput<br /> iput_final<br /> evict<br /> ntfs_evict_inode<br /> ni_write_inode<br /> is_rec_inuse(ni-&gt;mi.mrec)-&gt; As &amp;#39;ni-&gt;mi.mrec&amp;#39; is NULL trigger NULL-ptr-deref<br /> <br /> To solve above issue if new inode failed make inode bad before call &amp;#39;iput()&amp;#39; in<br /> &amp;#39;ntfs_new_inode()&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "Bluetooth: btsdio: fix use after free bug in btsdio_remove due to unfinished work"<br /> <br /> This reverts commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f.<br /> <br /> This patch introduces a possible null-ptr-def problem. Revert it. And the<br /> fixed bug by this patch have resolved by commit 73f7b171b7c0 ("Bluetooth:<br /> btsdio: fix use after free bug in btsdio_remove due to race condition").