Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6/addrconf: fix a potential refcount underflow for idev<br /> <br /> Now in addrconf_mod_rs_timer(), reference idev depends on whether<br /> rs_timer is not pending. Then modify rs_timer timeout.<br /> <br /> There is a time gap in [1], during which if the pending rs_timer<br /> becomes not pending. It will miss to hold idev, but the rs_timer<br /> is activated. Thus rs_timer callback function addrconf_rs_timer()<br /> will be executed and put idev later without holding idev. A refcount<br /> underflow issue for idev can be caused by this.<br /> <br /> if (!timer_pending(&amp;idev-&gt;rs_timer))<br /> in6_dev_hold(idev);<br /> rs_timer, jiffies + when);<br /> <br /> To fix the issue, hold idev if mod_timer() return 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix memory leaks in error path<br /> <br /> The memory allocated by vxlan_vnigroup_init() is not freed in the error<br /> path, leading to memory leaks [1]. Fix by calling<br /> vxlan_vnigroup_uninit() in the error path.<br /> <br /> The leaks can be reproduced by annotating gro_cells_init() with<br /> ALLOW_ERROR_INJECTION() and then running:<br /> <br /> # echo "100" &gt; /sys/kernel/debug/fail_function/probability<br /> # echo "1" &gt; /sys/kernel/debug/fail_function/times<br /> # echo "gro_cells_init" &gt; /sys/kernel/debug/fail_function/inject<br /> # printf %#x -12 &gt; /sys/kernel/debug/fail_function/gro_cells_init/retval<br /> # ip link add name vxlan0 type vxlan dstport 4789 external vnifilter<br /> RTNETLINK answers: Cannot allocate memory<br /> <br /> [1]<br /> unreferenced object 0xffff88810db84a00 (size 512):<br /> comm "ip", pid 330, jiffies 4295010045 (age 66.016s)<br /> hex dump (first 32 bytes):<br /> f8 d5 76 0e 81 88 ff ff 01 00 00 00 00 00 00 02 ..v.............<br /> 03 00 04 00 48 00 00 00 00 00 00 01 04 00 01 00 ....H...........<br /> backtrace:<br /> [] kmalloc_trace+0x2a/0x60<br /> [] vxlan_vnigroup_init+0x4c/0x160<br /> [] vxlan_init+0x1ae/0x280<br /> [] register_netdevice+0x57a/0x16d0<br /> [] __vxlan_dev_create+0x7c7/0xa50<br /> [] vxlan_newlink+0xd6/0x130<br /> [] __rtnl_newlink+0x112b/0x18a0<br /> [] rtnl_newlink+0x6c/0xa0<br /> [] rtnetlink_rcv_msg+0x43f/0xd40<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x53f/0x810<br /> [] netlink_sendmsg+0x958/0xe70<br /> [] ____sys_sendmsg+0x78f/0xa90<br /> [] ___sys_sendmsg+0x13a/0x1e0<br /> [] __sys_sendmsg+0x11c/0x1f0<br /> [] do_syscall_64+0x38/0x80<br /> unreferenced object 0xffff88810e76d5f8 (size 192):<br /> comm "ip", pid 330, jiffies 4295010045 (age 66.016s)<br /> hex dump (first 32 bytes):<br /> 04 00 00 00 00 00 00 00 db e1 4f e7 00 00 00 00 ..........O.....<br /> 08 d6 76 0e 81 88 ff ff 08 d6 76 0e 81 88 ff ff ..v.......v.....<br /> backtrace:<br /> [] __kmalloc_node+0x4e/0x90<br /> [] kvmalloc_node+0xa6/0x1f0<br /> [] bucket_table_alloc.isra.0+0x83/0x460<br /> [] rhashtable_init+0x43b/0x7c0<br /> [] vxlan_vnigroup_init+0x6c/0x160<br /> [] vxlan_init+0x1ae/0x280<br /> [] register_netdevice+0x57a/0x16d0<br /> [] __vxlan_dev_create+0x7c7/0xa50<br /> [] vxlan_newlink+0xd6/0x130<br /> [] __rtnl_newlink+0x112b/0x18a0<br /> [] rtnl_newlink+0x6c/0xa0<br /> [] rtnetlink_rcv_msg+0x43f/0xd40<br /> [] netlink_rcv_skb+0x170/0x440<br /> [] netlink_unicast+0x53f/0x810<br /> [] netlink_sendmsg+0x958/0xe70<br /> [] ____sys_sendmsg+0x78f/0xa90

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains<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 /> vxlan: Fix nexthop hash size<br /> <br /> The nexthop code expects a 31 bit hash, such as what is returned by<br /> fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash<br /> returned by skb_get_hash() can lead to problems related to the fact that<br /> &amp;#39;int hash&amp;#39; is a negative number when the MSB is set.<br /> <br /> In the case of hash threshold nexthop groups, nexthop_select_path_hthr()<br /> will disproportionately select the first nexthop group entry. In the case<br /> of resilient nexthop groups, nexthop_select_path_res() may do an out of<br /> bounds access in nh_buckets[], for example:<br /> hash = -912054133<br /> num_nh_buckets = 2<br /> bucket_index = 65535<br /> <br /> which leads to the following panic:<br /> <br /> BUG: unable to handle page fault for address: ffffc900025910c8<br /> PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:nexthop_select_path+0x197/0xbf0<br /> Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85<br /> RSP: 0018:ffff88810c36f260 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8<br /> RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219<br /> R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0<br /> R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900<br /> FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x1ee/0x5c0<br /> ? __pfx_is_prefetch.constprop.0+0x10/0x10<br /> ? __pfx_page_fault_oops+0x10/0x10<br /> ? search_bpf_extables+0xfe/0x1c0<br /> ? fixup_exception+0x3b/0x470<br /> ? exc_page_fault+0xf6/0x110<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? nexthop_select_path+0x197/0xbf0<br /> ? nexthop_select_path+0x197/0xbf0<br /> ? lock_is_held_type+0xe7/0x140<br /> vxlan_xmit+0x5b2/0x2340<br /> ? __lock_acquire+0x92b/0x3370<br /> ? __pfx_vxlan_xmit+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_register_lock_class+0x10/0x10<br /> ? skb_network_protocol+0xce/0x2d0<br /> ? dev_hard_start_xmit+0xca/0x350<br /> ? __pfx_vxlan_xmit+0x10/0x10<br /> dev_hard_start_xmit+0xca/0x350<br /> __dev_queue_xmit+0x513/0x1e20<br /> ? __pfx___dev_queue_xmit+0x10/0x10<br /> ? __pfx_lock_release+0x10/0x10<br /> ? mark_held_locks+0x44/0x90<br /> ? skb_push+0x4c/0x80<br /> ? eth_header+0x81/0xe0<br /> ? __pfx_eth_header+0x10/0x10<br /> ? neigh_resolve_output+0x215/0x310<br /> ? ip6_finish_output2+0x2ba/0xc90<br /> ip6_finish_output2+0x2ba/0xc90<br /> ? lock_release+0x236/0x3e0<br /> ? ip6_mtu+0xbb/0x240<br /> ? __pfx_ip6_finish_output2+0x10/0x10<br /> ? find_held_lock+0x83/0xa0<br /> ? lock_is_held_type+0xe7/0x140<br /> ip6_finish_output+0x1ee/0x780<br /> ip6_output+0x138/0x460<br /> ? __pfx_ip6_output+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_ip6_finish_output+0x10/0x10<br /> NF_HOOK.constprop.0+0xc0/0x420<br /> ? __pfx_NF_HOOK.constprop.0+0x10/0x10<br /> ? ndisc_send_skb+0x2c0/0x960<br /> ? __pfx_lock_release+0x10/0x10<br /> ? __local_bh_enable_ip+0x93/0x110<br /> ? lock_is_held_type+0xe7/0x140<br /> ndisc_send_skb+0x4be/0x960<br /> ? __pfx_ndisc_send_skb+0x10/0x10<br /> ? mark_held_locks+0x65/0x90<br /> ? find_held_lock+0x83/0xa0<br /> ndisc_send_ns+0xb0/0x110<br /> ? __pfx_ndisc_send_ns+0x10/0x10<br /> addrconf_dad_work+0x631/0x8e0<br /> ? lock_acquire+0x180/0x3f0<br /> ? __pfx_addrconf_dad_work+0x10/0x10<br /> ? mark_held_locks+0x24/0x90<br /> process_one_work+0x582/0x9c0<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> ? mark_held_locks+0x24/0x90<br /> worker_thread+0x93/0x630<br /> ? __kthread_parkme+0xdc/0x100<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1a5/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x60<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini<br /> <br /> The gmc.ecc_irq is enabled by firmware per IFWI setting,<br /> and the host driver is not privileged to enable/disable<br /> the interrupt. So, it is meaningless to use the amdgpu_irq_put<br /> function in gmc_v10_0_hw_fini, which also leads to the call<br /> trace.<br /> <br /> [ 82.340264] Call Trace:<br /> [ 82.340265] <br /> [ 82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu]<br /> [ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu]<br /> [ 82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu]<br /> [ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]<br /> [ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu]<br /> [ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu]<br /> [ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]<br /> [ 82.341529] process_one_work+0x21d/0x3f0<br /> [ 82.341535] worker_thread+0x1fa/0x3c0<br /> [ 82.341538] ? process_one_work+0x3f0/0x3f0<br /> [ 82.341540] kthread+0xff/0x130<br /> [ 82.341544] ? kthread_complete_and_exit+0x20/0x20<br /> [ 82.341547] ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add length check in indx_get_root<br /> <br /> This adds a length check to guarantee the retrieved index root is legit.<br /> <br /> [ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243<br /> [ 162.460851]<br /> [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42<br /> [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 162.462609] Call Trace:<br /> [ 162.462954] <br /> [ 162.463276] dump_stack_lvl+0x49/0x63<br /> [ 162.463822] print_report.cold+0xf5/0x689<br /> [ 162.464608] ? unwind_get_return_address+0x3a/0x60<br /> [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.466975] kasan_report+0xa7/0x130<br /> [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0<br /> [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.468536] __asan_load2+0x68/0x90<br /> [ 162.468923] hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.469282] ? cmp_uints+0xe0/0xe0<br /> [ 162.469557] ? cmp_sdh+0x90/0x90<br /> [ 162.469864] ? ni_find_attr+0x214/0x300<br /> [ 162.470217] ? ni_load_mi+0x80/0x80<br /> [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.470931] ? ntfs_bread_run+0x190/0x190<br /> [ 162.471307] ? indx_get_root+0xe4/0x190<br /> [ 162.471556] ? indx_get_root+0x140/0x190<br /> [ 162.471833] ? indx_init+0x1e0/0x1e0<br /> [ 162.472069] ? fnd_clear+0x115/0x140<br /> [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100<br /> [ 162.472731] indx_find+0x184/0x470<br /> [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0<br /> [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0<br /> [ 162.474704] ? do_syscall_64+0x3b/0x90<br /> [ 162.474962] dir_search_u+0x196/0x2f0<br /> [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450<br /> [ 162.475661] ? ntfs_security_init+0x3d6/0x440<br /> [ 162.475906] ? is_sd_valid+0x180/0x180<br /> [ 162.476191] ntfs_extend_init+0x13f/0x2c0<br /> [ 162.476496] ? ntfs_fix_post_read+0x130/0x130<br /> [ 162.476861] ? iput.part.0+0x286/0x320<br /> [ 162.477325] ntfs_fill_super+0x11e0/0x1b50<br /> [ 162.477709] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.477970] ? vsprintf+0x20/0x20<br /> [ 162.478258] ? set_blocksize+0x95/0x150<br /> [ 162.478538] get_tree_bdev+0x232/0x370<br /> [ 162.478789] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.479038] ntfs_fs_get_tree+0x15/0x20<br /> [ 162.479374] vfs_get_tree+0x4c/0x130<br /> [ 162.479729] path_mount+0x654/0xfe0<br /> [ 162.480124] ? putname+0x80/0xa0<br /> [ 162.480484] ? finish_automount+0x2e0/0x2e0<br /> [ 162.480894] ? putname+0x80/0xa0<br /> [ 162.481467] ? kmem_cache_free+0x1c4/0x440<br /> [ 162.482280] ? putname+0x80/0xa0<br /> [ 162.482714] do_mount+0xd6/0xf0<br /> [ 162.483264] ? path_mount+0xfe0/0xfe0<br /> [ 162.484782] ? __kasan_check_write+0x14/0x20<br /> [ 162.485593] __x64_sys_mount+0xca/0x110<br /> [ 162.486024] do_syscall_64+0x3b/0x90<br /> [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.487141] RIP: 0033:0x7f9d374e948a<br /> [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5<br /> [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a<br /> [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0<br /> [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020<br /> [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0<br /> [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 162.493644] <br /> [ 162.493908]<br /> [ 162.494214] The buggy address belongs to the physical page:<br /> [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc<br /> [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000<br /> [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000<br /> [ 162.500542] page dumped becau<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init<br /> <br /> The line cards array is not freed in the error path of<br /> mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by<br /> freeing the array in the error path, thereby making the error path<br /> identical to mlxsw_m_linecards_fini().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: qcom: Fix potential memory leak<br /> <br /> Function dwc3_qcom_probe() allocates memory for resource structure<br /> which is pointed by parent_res pointer. This memory is not<br /> freed. This leads to memory leak. Use stack memory to prevent<br /> memory leak.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Avoid NULL pointer access during management transmit cleanup<br /> <br /> Currently &amp;#39;ar&amp;#39; reference is not added in skb_cb.<br /> Though this is generally not used during transmit completion<br /> callbacks, on interface removal the remaining idr cleanup callback<br /> uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them<br /> during transmit call for proper usage to avoid NULL pointer dereference.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf/dma-resv: Stop leaking on krealloc() failure<br /> <br /> Currently dma_resv_get_fences() will leak the previously<br /> allocated array if the fence iteration got restarted and<br /> the krealloc_array() fails.<br /> <br /> Free the old array by hand, and make sure we still clear<br /> the returned *fences so the caller won&amp;#39;t end up accessing<br /> freed memory. Some (but not all) of the callers of<br /> dma_resv_get_fences() seem to still trawl through the<br /> array even when dma_resv_get_fences() failed. And let&amp;#39;s<br /> zero out *num_fences as well for good measure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Avoid undefined behavior: applying zero offset to null pointer<br /> <br /> ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e<br /> <br /> Before this change we see the following UBSAN stack trace in Fuchsia:<br /> <br /> #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 +0x233302<br /> #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 +0x3d77f<br /> #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 +0x3d77f<br /> #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 +0x3d77f<br /> #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 +0x4196d<br /> #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 +0x4150d<br /> #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 +0x233302<br /> #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 +0x262369<br /> #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 +0x2b7fac<br /> #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 +0x2c64d2<br /> #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 +0x22a052<br /> #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 +0x293dd8<br /> #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 +0x2a9e98<br /> #11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 +0x2931ac<br /> #12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 +0x2fc40d<br /> #13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 +0xed603<br /> <br /> Add a simple check that avoids incrementing a pointer by zero, but<br /> otherwise behaves as before. Note that our findings are against ACPICA<br /> 20221020, but the same code exists on master.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: exit gracefully if reloc roots don&amp;#39;t match<br /> <br /> [BUG]<br /> Syzbot reported a crash that an ASSERT() got triggered inside<br /> prepare_to_merge().<br /> <br /> [CAUSE]<br /> The root cause of the triggered ASSERT() is we can have a race between<br /> quota tree creation and relocation.<br /> <br /> This leads us to create a duplicated quota tree in the<br /> btrfs_read_fs_root() path, and since it&amp;#39;s treated as fs tree, it would<br /> have ROOT_SHAREABLE flag, causing us to create a reloc tree for it.<br /> <br /> The bug itself is fixed by a dedicated patch for it, but this already<br /> taught us the ASSERT() is not something straightforward for<br /> developers.<br /> <br /> [ENHANCEMENT]<br /> Instead of using an ASSERT(), let&amp;#39;s handle it gracefully and output<br /> extra info about the mismatch reloc roots to help debug.<br /> <br /> Also with the above ASSERT() removed, we can trigger ASSERT(0)s inside<br /> merge_reloc_roots() later.<br /> Also replace those ASSERT(0)s with WARN_ON()s.