Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free when attempting to join an aborted transaction<br /> <br /> When we are trying to join the current transaction and if it&amp;#39;s aborted,<br /> we read its &amp;#39;aborted&amp;#39; field after unlocking fs_info-&gt;trans_lock and<br /> without holding any extra reference count on it. This means that a<br /> concurrent task that is aborting the transaction may free the transaction<br /> before we read its &amp;#39;aborted&amp;#39; field, leading to a use-after-free.<br /> <br /> Fix this by reading the &amp;#39;aborted&amp;#39; field while holding fs_info-&gt;trans_lock<br /> since any freeing task must first acquire that lock and set<br /> fs_info-&gt;running_transaction to NULL before freeing the transaction.<br /> <br /> This was reported by syzbot and Dmitry with the following stack traces<br /> from KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278<br /> Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128<br /> <br /> CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: events_unbound btrfs_async_reclaim_data_space<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278<br /> start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697<br /> flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803<br /> btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321<br /> process_one_work kernel/workqueue.c:3236 [inline]<br /> process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3398<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Allocated by task 5315:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329<br /> kmalloc_noprof include/linux/slab.h:901 [inline]<br /> join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308<br /> start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697<br /> btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572<br /> lookup_open fs/namei.c:3649 [inline]<br /> open_last_lookups fs/namei.c:3748 [inline]<br /> path_openat+0x1c03/0x3590 fs/namei.c:3984<br /> do_filp_open+0x27f/0x4e0 fs/namei.c:4014<br /> do_sys_openat2+0x13e/0x1d0 fs/open.c:1402<br /> do_sys_open fs/open.c:1417 [inline]<br /> __do_sys_creat fs/open.c:1495 [inline]<br /> __se_sys_creat fs/open.c:1489 [inline]<br /> __x64_sys_creat+0x123/0x170 fs/open.c:1489<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 5336:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582<br /> poison_slab_object mm/kasan/common.c:247 [inline]<br /> __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264<br /> kasan_slab_free include/linux/kasan.h:233 [inline]<br /> slab_free_hook mm/slub.c:2353 [inline]<br /> slab_free mm/slub.c:4613 [inline]<br /> kfree+0x196/0x430 mm/slub.c:4761<br /> cleanup_transaction fs/btrfs/transaction.c:2063 [inline]<br /> btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598<br /> insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757<br /> btrfs_balance+0x992/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()<br /> <br /> On removal of the device or unloading of the kernel module a potential NULL<br /> pointer dereference occurs.<br /> <br /> The following sequence deletes the interface:<br /> <br /> brcmf_detach()<br /> brcmf_remove_interface()<br /> brcmf_del_if()<br /> <br /> Inside the brcmf_del_if() function the drvr-&gt;if2bss[ifidx] is updated to<br /> BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.<br /> <br /> After brcmf_remove_interface() call the brcmf_proto_detach() function is<br /> called providing the following sequence:<br /> <br /> brcmf_detach()<br /> brcmf_proto_detach()<br /> brcmf_proto_msgbuf_detach()<br /> brcmf_flowring_detach()<br /> brcmf_msgbuf_delete_flowring()<br /> brcmf_msgbuf_remove_flowring()<br /> brcmf_flowring_delete()<br /> brcmf_get_ifp()<br /> brcmf_txfinalize()<br /> <br /> Since brcmf_get_ip() can and actually will return NULL in this case the<br /> call to brcmf_txfinalize() will result in a NULL pointer dereference inside<br /> brcmf_txfinalize() when trying to update ifp-&gt;ndev-&gt;stats.tx_errors.<br /> <br /> This will only happen if a flowring still has an skb.<br /> <br /> Although the NULL pointer dereference has only been seen when trying to<br /> update the tx statistic, all other uses of the ifp pointer have been<br /> guarded as well with an early return if ifp is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: Fix class @block_class&amp;#39;s subsystem refcount leakage<br /> <br /> blkcg_fill_root_iostats() iterates over @block_class&amp;#39;s devices by<br /> class_dev_iter_(init|next)(), but does not end iterating with<br /> class_dev_iter_exit(), so causes the class&amp;#39;s subsystem refcount leakage.<br /> <br /> Fix by ending the iterating with class_dev_iter_exit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix integer overflows on 32 bit systems<br /> <br /> On 32bit systems the addition operations in ipc_msg_alloc() can<br /> potentially overflow leading to memory corruption.<br /> Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rose: lock the socket in rose_bind()<br /> <br /> syzbot reported a soft lockup in rose_loopback_timer(),<br /> with a repro calling bind() from multiple threads.<br /> <br /> rose_bind() must lock the socket to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics - fix crash when enabling pass-through port<br /> <br /> When enabling a pass-through port an interrupt might come before psmouse<br /> driver binds to the pass-through port. However synaptics sub-driver<br /> tries to access psmouse instance presumably associated with the<br /> pass-through port to figure out if only 1 byte of response or entire<br /> protocol packet needs to be forwarded to the pass-through port and may<br /> crash if psmouse instance has not been attached to the port yet.<br /> <br /> Fix the crash by introducing open() and close() methods for the port and<br /> check if the port is open before trying to access psmouse instance.<br /> Because psmouse calls serio_open() only after attaching psmouse instance<br /> to serio port instance this prevents the potential crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ast: astdp: Fix timeout for enabling video signal<br /> <br /> The ASTDP transmitter sometimes takes up to 1 second for enabling the<br /> video signal, while the timeout is only 200 msec. This results in a<br /> kernel error message. Increase the timeout to 1 second. An example<br /> of the error message is shown below.<br /> <br /> [ 697.084433] ------------[ cut here ]------------<br /> [ 697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled))<br /> [ 697.091233] WARNING: CPU: 1 PID: 160 at drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast]<br /> [...]<br /> [ 697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast]<br /> [...]<br /> [ 697.415283] Call Trace:<br /> [ 697.420727] <br /> [ 697.425908] ? show_trace_log_lvl+0x196/0x2c0<br /> [ 697.433304] ? show_trace_log_lvl+0x196/0x2c0<br /> [ 697.440693] ? drm_atomic_helper_commit_modeset_enables+0x30a/0x470<br /> [ 697.450115] ? ast_dp_set_enable+0x123/0x140 [ast]<br /> [ 697.458059] ? __warn.cold+0xaf/0xca<br /> [ 697.464713] ? ast_dp_set_enable+0x123/0x140 [ast]<br /> [ 697.472633] ? report_bug+0x134/0x1d0<br /> [ 697.479544] ? handle_bug+0x58/0x90<br /> [ 697.486127] ? exc_invalid_op+0x13/0x40<br /> [ 697.492975] ? asm_exc_invalid_op+0x16/0x20<br /> [ 697.500224] ? preempt_count_sub+0x14/0xc0<br /> [ 697.507473] ? ast_dp_set_enable+0x123/0x140 [ast]<br /> [ 697.515377] ? ast_dp_set_enable+0x123/0x140 [ast]<br /> [ 697.523227] drm_atomic_helper_commit_modeset_enables+0x30a/0x470<br /> [ 697.532388] drm_atomic_helper_commit_tail+0x58/0x90<br /> [ 697.540400] ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast]<br /> [ 697.550009] commit_tail+0xfe/0x1d0<br /> [ 697.556547] drm_atomic_helper_commit+0x198/0x1c0<br /> <br /> This is a cosmetical problem. Enabling the video signal still works<br /> even with the error message. The problem has always been present, but<br /> only recent versions of the ast driver warn about missing the timeout.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Check the return value of of_property_read_string_index()<br /> <br /> Somewhen between 6.10 and 6.11 the driver started to crash on my<br /> MacBookPro14,3. The property doesn&amp;#39;t exist and &amp;#39;tmp&amp;#39; remains<br /> uninitialized, so we pass a random pointer to devm_kstrdup().<br /> <br /> The crash I am getting looks like this:<br /> <br /> BUG: unable to handle page fault for address: 00007f033c669379<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0001) - permissions violation<br /> PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025<br /> Oops: Oops: 0001 [#1] SMP PTI<br /> CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1<br /> Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024<br /> RIP: 0010:strlen+0x4/0x30<br /> Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc<br /> RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202<br /> RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001<br /> RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379<br /> RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a<br /> R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8<br /> R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30<br /> FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x149/0x4c0<br /> ? raw_spin_rq_lock_nested+0xe/0x20<br /> ? sched_balance_newidle+0x22b/0x3c0<br /> ? update_load_avg+0x78/0x770<br /> ? exc_page_fault+0x6f/0x150<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? __pfx_pci_conf1_write+0x10/0x10<br /> ? strlen+0x4/0x30<br /> devm_kstrdup+0x25/0x70<br /> brcmf_of_probe+0x273/0x350 [brcmfmac]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t use btrfs_set_item_key_safe on RAID stripe-extents<br /> <br /> Don&amp;#39;t use btrfs_set_item_key_safe() to modify the keys in the RAID<br /> stripe-tree, as this can lead to corruption of the tree, which is caught<br /> by the checks in btrfs_set_item_key_safe():<br /> <br /> BTRFS info (device nvme1n1): leaf 49168384 gen 15 total ptrs 194 free space 8329 owner 12<br /> BTRFS info (device nvme1n1): refs 2 lock_owner 1030 current 1030<br /> [ snip ]<br /> item 105 key (354549760 230 20480) itemoff 14587 itemsize 16<br /> stride 0 devid 5 physical 67502080<br /> item 106 key (354631680 230 4096) itemoff 14571 itemsize 16<br /> stride 0 devid 1 physical 88559616<br /> item 107 key (354631680 230 32768) itemoff 14555 itemsize 16<br /> stride 0 devid 1 physical 88555520<br /> item 108 key (354717696 230 28672) itemoff 14539 itemsize 16<br /> stride 0 devid 2 physical 67604480<br /> [ snip ]<br /> BTRFS critical (device nvme1n1): slot 106 key (354631680 230 32768) new key (354635776 230 4096)<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/ctree.c:2602!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 UID: 0 PID: 1055 Comm: fsstress Not tainted 6.13.0-rc1+ #1464<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> RIP: 0010:btrfs_set_item_key_safe+0xf7/0x270<br /> Code: <br /> RSP: 0018:ffffc90001337ab0 EFLAGS: 00010287<br /> RAX: 0000000000000000 RBX: ffff8881115fd000 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000001 RDI: 00000000ffffffff<br /> RBP: ffff888110ed6f50 R08: 00000000ffffefff R09: ffffffff8244c500<br /> R10: 00000000ffffefff R11: 00000000ffffffff R12: ffff888100586000<br /> R13: 00000000000000c9 R14: ffffc90001337b1f R15: ffff888110f23b58<br /> FS: 00007f7d75c72740(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa811652c60 CR3: 0000000111398001 CR4: 0000000000370eb0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x14/0x1a<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x65/0x80<br /> ? btrfs_set_item_key_safe+0xf7/0x270<br /> ? exc_invalid_op+0x50/0x70<br /> ? btrfs_set_item_key_safe+0xf7/0x270<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? btrfs_set_item_key_safe+0xf7/0x270<br /> btrfs_partially_delete_raid_extent+0xc4/0xe0<br /> btrfs_delete_raid_extent+0x227/0x240<br /> __btrfs_free_extent.isra.0+0x57f/0x9c0<br /> ? exc_coproc_segment_overrun+0x40/0x40<br /> __btrfs_run_delayed_refs+0x2fa/0xe80<br /> btrfs_run_delayed_refs+0x81/0xe0<br /> btrfs_commit_transaction+0x2dd/0xbe0<br /> ? preempt_count_add+0x52/0xb0<br /> btrfs_sync_file+0x375/0x4c0<br /> do_fsync+0x39/0x70<br /> __x64_sys_fsync+0x13/0x20<br /> do_syscall_64+0x54/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f7d7550ef90<br /> Code: <br /> RSP: 002b:00007ffd70237248 EFLAGS: 00000202 ORIG_RAX: 000000000000004a<br /> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f7d7550ef90<br /> RDX: 000000000000013a RSI: 000000000040eb28 RDI: 0000000000000004<br /> RBP: 000000000000001b R08: 0000000000000078 R09: 00007ffd7023725c<br /> R10: 00007f7d75400390 R11: 0000000000000202 R12: 028f5c28f5c28f5c<br /> R13: 8f5c28f5c28f5c29 R14: 000000000040b520 R15: 00007f7d75c726c8<br /> <br /> <br /> While the root cause of the tree order corruption isn&amp;#39;t clear, using<br /> btrfs_duplicate_item() to copy the item and then adjusting both the key<br /> and the per-device physical addresses is a safe way to counter this<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix use-after free in init error and remove paths<br /> <br /> devm_blk_crypto_profile_init() registers a cleanup handler to run when<br /> the associated (platform-) device is being released. For UFS, the<br /> crypto private data and pointers are stored as part of the ufs_hba&amp;#39;s<br /> data structure &amp;#39;struct ufs_hba::crypto_profile&amp;#39;. This structure is<br /> allocated as part of the underlying ufshcd and therefore Scsi_host<br /> allocation.<br /> <br /> During driver release or during error handling in ufshcd_pltfrm_init(),<br /> this structure is released as part of ufshcd_dealloc_host() before the<br /> (platform-) device associated with the crypto call above is released.<br /> Once this device is released, the crypto cleanup code will run, using<br /> the just-released &amp;#39;struct ufs_hba::crypto_profile&amp;#39;. This causes a<br /> use-after-free situation:<br /> <br /> Call trace:<br /> kfree+0x60/0x2d8 (P)<br /> kvfree+0x44/0x60<br /> blk_crypto_profile_destroy_callback+0x28/0x70<br /> devm_action_release+0x1c/0x30<br /> release_nodes+0x6c/0x108<br /> devres_release_all+0x98/0x100<br /> device_unbind_cleanup+0x20/0x70<br /> really_probe+0x218/0x2d0<br /> <br /> In other words, the initialisation code flow is:<br /> <br /> platform-device probe<br /> ufshcd_pltfrm_init()<br /> ufshcd_alloc_host()<br /> scsi_host_alloc()<br /> allocation of struct ufs_hba<br /> creation of scsi-host devices<br /> devm_blk_crypto_profile_init()<br /> devm registration of cleanup handler using platform-device<br /> <br /> and during error handling of ufshcd_pltfrm_init() or during driver<br /> removal:<br /> <br /> ufshcd_dealloc_host()<br /> scsi_host_put()<br /> put_device(scsi-host)<br /> release of struct ufs_hba<br /> put_device(platform-device)<br /> crypto cleanup handler<br /> <br /> To fix this use-after free, change ufshcd_alloc_host() to register a<br /> devres action to automatically cleanup the underlying SCSI device on<br /> ufshcd destruction, without requiring explicit calls to<br /> ufshcd_dealloc_host(). This way:<br /> <br /> * the crypto profile and all other ufs_hba-owned resources are<br /> destroyed before SCSI (as they&amp;#39;ve been registered after)<br /> * a memleak is plugged in tc-dwc-g210-pci.c remove() as a<br /> side-effect<br /> * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as<br /> it&amp;#39;s not needed anymore<br /> * no future drivers using ufshcd_alloc_host() could ever forget<br /> adding the cleanup

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: nci: Add bounds checking in nci_hci_create_pipe()<br /> <br /> The "pipe" variable is a u8 which comes from the network. If it&amp;#39;s more<br /> than 127, then it results in memory corruption in the caller,<br /> nci_hci_connect_gate().