Vulnerabilities

A logic issue was addressed with improved checks. This issue is fixed in iOS 17.5 and iPadOS 17.5, tvOS 17.5, watchOS 10.5, macOS Sonoma 14.5. An attacker may be able to access user data.

The issue was addressed with improved checks. This issue is fixed in iOS 17.5 and iPadOS 17.5, macOS Sonoma 14.5. An attacker may be able to elevate privileges.

An authorization issue was addressed with improved state management. This issue is fixed in macOS Sonoma 14.5. An attacker may be able to elevate privileges.

A permissions issue was addressed with improved validation. This issue is fixed in iOS 17.5 and iPadOS 17.5. An attacker with physical access may be able to share items from the lock screen.

The issue was addressed with improved checks. This issue is fixed in iTunes 12.13.2 for Windows. Parsing a file may lead to an unexpected app termination or arbitrary code execution.

A logic issue was addressed with improved checks. This issue is fixed in iOS 16.7.8 and iPadOS 16.7.8, macOS Monterey 12.7.5, macOS Ventura 13.6.7, macOS Sonoma 14.4. An app may be able to access user-sensitive data.

Claris International has resolved an issue of potentially allowing unauthorized access to records stored in databases hosted on FileMaker Server. This issue has been fixed in FileMaker Server 20.3.2 by validating transactions before replying to client requests.

A privilege escalation exists in the updater for Plantronics Hub 3.25.1 and below.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: once more fix the call oder in amdgpu_ttm_move() v2<br /> <br /> This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move<br /> on same heap. The basic problem here is that after the move the old<br /> location is simply not available any more.<br /> <br /> Some fixes were suggested, but essentially we should call the move<br /> notification before actually moving things because only this way we have<br /> the correct order for DMA-buf and VM move notifications as well.<br /> <br /> Also rework the statistic handling so that we don&amp;#39;t update the eviction<br /> counter before the move.<br /> <br /> v2: add missing NULL check

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: nosy: ensure user_length is taken into account when fetching packet contents<br /> <br /> Ensure that packet_buffer_get respects the user_length provided. If<br /> the length of the head packet exceeds the user_length, packet_buffer_get<br /> will now return 0 to signify to the user that no data were read<br /> and a larger buffer size is required. Helps prevent user space overflows.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout<br /> <br /> When the sco connection is established and then, the sco socket<br /> is releasing, timeout_work will be scheduled to judge whether<br /> the sco disconnection is timeout. The sock will be deallocated<br /> later, but it is dereferenced again in sco_sock_timeout. As a<br /> result, the use-after-free bugs will happen. The root cause is<br /> shown below:<br /> <br /> Cleanup Thread | Worker Thread<br /> sco_sock_release |<br /> sco_sock_close |<br /> __sco_sock_close |<br /> sco_sock_set_timer |<br /> schedule_delayed_work |<br /> sco_sock_kill | (wait a time)<br /> sock_put(sk) //FREE | sco_sock_timeout<br /> | sock_hold(sk) //USE<br /> <br /> The KASAN report triggered by POC is shown below:<br /> <br /> [ 95.890016] ==================================================================<br /> [ 95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0<br /> [ 95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7<br /> ...<br /> [ 95.890755] Workqueue: events sco_sock_timeout<br /> [ 95.890755] Call Trace:<br /> [ 95.890755] <br /> [ 95.890755] dump_stack_lvl+0x45/0x110<br /> [ 95.890755] print_address_description+0x78/0x390<br /> [ 95.890755] print_report+0x11b/0x250<br /> [ 95.890755] ? __virt_addr_valid+0xbe/0xf0<br /> [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0<br /> [ 95.890755] kasan_report+0x139/0x170<br /> [ 95.890755] ? update_load_avg+0xe5/0x9f0<br /> [ 95.890755] ? sco_sock_timeout+0x5e/0x1c0<br /> [ 95.890755] kasan_check_range+0x2c3/0x2e0<br /> [ 95.890755] sco_sock_timeout+0x5e/0x1c0<br /> [ 95.890755] process_one_work+0x561/0xc50<br /> [ 95.890755] worker_thread+0xab2/0x13c0<br /> [ 95.890755] ? pr_cont_work+0x490/0x490<br /> [ 95.890755] kthread+0x279/0x300<br /> [ 95.890755] ? pr_cont_work+0x490/0x490<br /> [ 95.890755] ? kthread_blkcg+0xa0/0xa0<br /> [ 95.890755] ret_from_fork+0x34/0x60<br /> [ 95.890755] ? kthread_blkcg+0xa0/0xa0<br /> [ 95.890755] ret_from_fork_asm+0x11/0x20<br /> [ 95.890755] <br /> [ 95.890755]<br /> [ 95.890755] Allocated by task 506:<br /> [ 95.890755] kasan_save_track+0x3f/0x70<br /> [ 95.890755] __kasan_kmalloc+0x86/0x90<br /> [ 95.890755] __kmalloc+0x17f/0x360<br /> [ 95.890755] sk_prot_alloc+0xe1/0x1a0<br /> [ 95.890755] sk_alloc+0x31/0x4e0<br /> [ 95.890755] bt_sock_alloc+0x2b/0x2a0<br /> [ 95.890755] sco_sock_create+0xad/0x320<br /> [ 95.890755] bt_sock_create+0x145/0x320<br /> [ 95.890755] __sock_create+0x2e1/0x650<br /> [ 95.890755] __sys_socket+0xd0/0x280<br /> [ 95.890755] __x64_sys_socket+0x75/0x80<br /> [ 95.890755] do_syscall_64+0xc4/0x1b0<br /> [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 95.890755]<br /> [ 95.890755] Freed by task 506:<br /> [ 95.890755] kasan_save_track+0x3f/0x70<br /> [ 95.890755] kasan_save_free_info+0x40/0x50<br /> [ 95.890755] poison_slab_object+0x118/0x180<br /> [ 95.890755] __kasan_slab_free+0x12/0x30<br /> [ 95.890755] kfree+0xb2/0x240<br /> [ 95.890755] __sk_destruct+0x317/0x410<br /> [ 95.890755] sco_sock_release+0x232/0x280<br /> [ 95.890755] sock_close+0xb2/0x210<br /> [ 95.890755] __fput+0x37f/0x770<br /> [ 95.890755] task_work_run+0x1ae/0x210<br /> [ 95.890755] get_signal+0xe17/0xf70<br /> [ 95.890755] arch_do_signal_or_restart+0x3f/0x520<br /> [ 95.890755] syscall_exit_to_user_mode+0x55/0x120<br /> [ 95.890755] do_syscall_64+0xd1/0x1b0<br /> [ 95.890755] entry_SYSCALL_64_after_hwframe+0x67/0x6f<br /> [ 95.890755]<br /> [ 95.890755] The buggy address belongs to the object at ffff88800c388000<br /> [ 95.890755] which belongs to the cache kmalloc-1k of size 1024<br /> [ 95.890755] The buggy address is located 128 bytes inside of<br /> [ 95.890755] freed 1024-byte region [ffff88800c388000, ffff88800c388400)<br /> [ 95.890755]<br /> [ 95.890755] The buggy address belongs to the physical page:<br /> [ 95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388<br /> [ 95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> [ 95.890755] ano<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout<br /> <br /> There is a race condition between l2cap_chan_timeout() and<br /> l2cap_chan_del(). When we use l2cap_chan_del() to delete the<br /> channel, the chan-&gt;conn will be set to null. But the conn could<br /> be dereferenced again in the mutex_lock() of l2cap_chan_timeout().<br /> As a result the null pointer dereference bug will happen. The<br /> KASAN report triggered by POC is shown below:<br /> <br /> [ 472.074580] ==================================================================<br /> [ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0<br /> [ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7<br /> [ 472.075308]<br /> [ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36<br /> [ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4<br /> [ 472.075308] Workqueue: events l2cap_chan_timeout<br /> [ 472.075308] Call Trace:<br /> [ 472.075308] <br /> [ 472.075308] dump_stack_lvl+0x137/0x1a0<br /> [ 472.075308] print_report+0x101/0x250<br /> [ 472.075308] ? __virt_addr_valid+0x77/0x160<br /> [ 472.075308] ? mutex_lock+0x68/0xc0<br /> [ 472.075308] kasan_report+0x139/0x170<br /> [ 472.075308] ? mutex_lock+0x68/0xc0<br /> [ 472.075308] kasan_check_range+0x2c3/0x2e0<br /> [ 472.075308] mutex_lock+0x68/0xc0<br /> [ 472.075308] l2cap_chan_timeout+0x181/0x300<br /> [ 472.075308] process_one_work+0x5d2/0xe00<br /> [ 472.075308] worker_thread+0xe1d/0x1660<br /> [ 472.075308] ? pr_cont_work+0x5e0/0x5e0<br /> [ 472.075308] kthread+0x2b7/0x350<br /> [ 472.075308] ? pr_cont_work+0x5e0/0x5e0<br /> [ 472.075308] ? kthread_blkcg+0xd0/0xd0<br /> [ 472.075308] ret_from_fork+0x4d/0x80<br /> [ 472.075308] ? kthread_blkcg+0xd0/0xd0<br /> [ 472.075308] ret_from_fork_asm+0x11/0x20<br /> [ 472.075308] <br /> [ 472.075308] ==================================================================<br /> [ 472.094860] Disabling lock debugging due to kernel taint<br /> [ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158<br /> [ 472.096136] #PF: supervisor write access in kernel mode<br /> [ 472.096136] #PF: error_code(0x0002) - not-present page<br /> [ 472.096136] PGD 0 P4D 0<br /> [ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> [ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36<br /> [ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4<br /> [ 472.096136] Workqueue: events l2cap_chan_timeout<br /> [ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0<br /> [ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88<br /> [ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246<br /> [ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865<br /> [ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78<br /> [ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f<br /> [ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000<br /> [ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00<br /> [ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000<br /> [ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0<br /> [ 472.096136] Call Trace:<br /> [ 472.096136] <br /> [ 472.096136] ? __die_body+0x8d/0xe0<br /> [ 472.096136] ? page_fault_oops+0x6b8/0x9a0<br /> [ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0<br /> [ 472.096136] ? do_user_addr_fault+0x1027/0x1340<br /> [ 472.096136] ? _printk+0x7a/0xa0<br /> [ 472.096136] ? mutex_lock+0x68/0xc0<br /> [ 472.096136] ? add_taint+0x42/0xd0<br /> [ 472.096136] ? exc_page_fault+0x6a/0x1b0<br /> [ 472.096136] ? asm_exc_page_fault+0x26/0x30<br /> [ 472.096136] ? mutex_lock+0x75/0xc0<br /> [ 472.096136] ? mutex_lock+0x88/0xc0<br /> [ 472.096136] ? mutex_lock+0x75/0xc0<br /> [ 472.096136] l2cap_chan_timeo<br /> ---truncated---