Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-compress: Reposition and add pcm_mutex<br /> <br /> If panic_on_warn is set and compress stream(DPCM) is started,<br /> then kernel panic occurred because card-&gt;pcm_mutex isn&amp;#39;t held appropriately.<br /> In the following functions, warning were issued at this line<br /> "snd_soc_dpcm_mutex_assert_held".<br /> <br /> static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe,<br /> struct snd_soc_pcm_runtime *be, int stream)<br /> {<br /> ...<br /> snd_soc_dpcm_mutex_assert_held(fe);<br /> ...<br /> }<br /> <br /> void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream)<br /> {<br /> ...<br /> snd_soc_dpcm_mutex_assert_held(fe);<br /> ...<br /> }<br /> <br /> void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd,<br /> int stream, int action)<br /> {<br /> ...<br /> snd_soc_dpcm_mutex_assert_held(rtd);<br /> ...<br /> }<br /> <br /> int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir,<br /> int event)<br /> {<br /> ...<br /> snd_soc_dpcm_mutex_assert_held(fe);<br /> ...<br /> }<br /> <br /> These functions are called by soc_compr_set_params_fe, soc_compr_open_fe<br /> and soc_compr_free_fe<br /> without pcm_mutex locking. And this is call stack.<br /> <br /> [ 414.527841][ T2179] pc : dpcm_process_paths+0x5a4/0x750<br /> [ 414.527848][ T2179] lr : dpcm_process_paths+0x37c/0x750<br /> [ 414.527945][ T2179] Call trace:<br /> [ 414.527949][ T2179] dpcm_process_paths+0x5a4/0x750<br /> [ 414.527955][ T2179] soc_compr_open_fe+0xb0/0x2cc<br /> [ 414.527972][ T2179] snd_compr_open+0x180/0x248<br /> [ 414.527981][ T2179] snd_open+0x15c/0x194<br /> [ 414.528003][ T2179] chrdev_open+0x1b0/0x220<br /> [ 414.528023][ T2179] do_dentry_open+0x30c/0x594<br /> [ 414.528045][ T2179] vfs_open+0x34/0x44<br /> [ 414.528053][ T2179] path_openat+0x914/0xb08<br /> [ 414.528062][ T2179] do_filp_open+0xc0/0x170<br /> [ 414.528068][ T2179] do_sys_openat2+0x94/0x18c<br /> [ 414.528076][ T2179] __arm64_sys_openat+0x78/0xa4<br /> [ 414.528084][ T2179] invoke_syscall+0x48/0x10c<br /> [ 414.528094][ T2179] el0_svc_common+0xbc/0x104<br /> [ 414.528099][ T2179] do_el0_svc+0x34/0xd8<br /> [ 414.528103][ T2179] el0_svc+0x34/0xc4<br /> [ 414.528125][ T2179] el0t_64_sync_handler+0x8c/0xfc<br /> [ 414.528133][ T2179] el0t_64_sync+0x1a0/0x1a4<br /> [ 414.528142][ T2179] Kernel panic - not syncing: panic_on_warn set ...<br /> <br /> So, I reposition and add pcm_mutex to resolve lockdep error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: do not hard code device address lenth in fdb dumps<br /> <br /> syzbot reports that some netdev devices do not have a six bytes<br /> address [1]<br /> <br /> Replace ETH_ALEN by dev-&gt;addr_len.<br /> <br /> [1] (Case of a device where dev-&gt;addr_len = 4)<br /> <br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> BUG: KMSAN: kernel-infoleak in copyout+0xb8/0x100 lib/iov_iter.c:169<br /> instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> copyout+0xb8/0x100 lib/iov_iter.c:169<br /> _copy_to_iter+0x6d8/0x1d00 lib/iov_iter.c:536<br /> copy_to_iter include/linux/uio.h:206 [inline]<br /> simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:513<br /> __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419<br /> skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:527<br /> skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]<br /> netlink_recvmsg+0x4ae/0x15a0 net/netlink/af_netlink.c:1970<br /> sock_recvmsg_nosec net/socket.c:1019 [inline]<br /> sock_recvmsg net/socket.c:1040 [inline]<br /> ____sys_recvmsg+0x283/0x7f0 net/socket.c:2722<br /> ___sys_recvmsg+0x223/0x840 net/socket.c:2764<br /> do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858<br /> __sys_recvmmsg net/socket.c:2937 [inline]<br /> __do_sys_recvmmsg net/socket.c:2960 [inline]<br /> __se_sys_recvmmsg net/socket.c:2953 [inline]<br /> __x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was stored to memory at:<br /> __nla_put lib/nlattr.c:1009 [inline]<br /> nla_put+0x1c6/0x230 lib/nlattr.c:1067<br /> nlmsg_populate_fdb_fill+0x2b8/0x600 net/core/rtnetlink.c:4071<br /> nlmsg_populate_fdb net/core/rtnetlink.c:4418 [inline]<br /> ndo_dflt_fdb_dump+0x616/0x840 net/core/rtnetlink.c:4456<br /> rtnl_fdb_dump+0x14ff/0x1fc0 net/core/rtnetlink.c:4629<br /> netlink_dump+0x9d1/0x1310 net/netlink/af_netlink.c:2268<br /> netlink_recvmsg+0xc5c/0x15a0 net/netlink/af_netlink.c:1995<br /> sock_recvmsg_nosec+0x7a/0x120 net/socket.c:1019<br /> ____sys_recvmsg+0x664/0x7f0 net/socket.c:2720<br /> ___sys_recvmsg+0x223/0x840 net/socket.c:2764<br /> do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858<br /> __sys_recvmmsg net/socket.c:2937 [inline]<br /> __do_sys_recvmmsg net/socket.c:2960 [inline]<br /> __se_sys_recvmmsg net/socket.c:2953 [inline]<br /> __x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716<br /> slab_alloc_node mm/slub.c:3451 [inline]<br /> __kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490<br /> kmalloc_trace+0x51/0x200 mm/slab_common.c:1057<br /> kmalloc include/linux/slab.h:559 [inline]<br /> __hw_addr_create net/core/dev_addr_lists.c:60 [inline]<br /> __hw_addr_add_ex+0x2e5/0x9e0 net/core/dev_addr_lists.c:118<br /> __dev_mc_add net/core/dev_addr_lists.c:867 [inline]<br /> dev_mc_add+0x9a/0x130 net/core/dev_addr_lists.c:885<br /> igmp6_group_added+0x267/0xbc0 net/ipv6/mcast.c:680<br /> ipv6_mc_up+0x296/0x3b0 net/ipv6/mcast.c:2754<br /> ipv6_mc_remap+0x1e/0x30 net/ipv6/mcast.c:2708<br /> addrconf_type_change net/ipv6/addrconf.c:3731 [inline]<br /> addrconf_notify+0x4d3/0x1d90 net/ipv6/addrconf.c:3699<br /> notifier_call_chain kernel/notifier.c:93 [inline]<br /> raw_notifier_call_chain+0xe4/0x430 kernel/notifier.c:461<br /> call_netdevice_notifiers_info net/core/dev.c:1935 [inline]<br /> call_netdevice_notifiers_extack net/core/dev.c:1973 [inline]<br /> call_netdevice_notifiers+0x1ee/0x2d0 net/core/dev.c:1987<br /> bond_enslave+0xccd/0x53f0 drivers/net/bonding/bond_main.c:1906<br /> do_set_master net/core/rtnetlink.c:2626 [inline]<br /> rtnl_newlink_create net/core/rtnetlink.c:3460 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3660 [inline]<br /> rtnl_newlink+0x378c/0x40e0 net/core/rtnetlink.c:3673<br /> rtnetlink_rcv_msg+0x16a6/0x1840 net/core/rtnetlink.c:6395<br /> netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2546<br /> rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6413<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0xf28/0x1230 net/netlink/af_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()<br /> <br /> When disabling overlay plane in mxsfb_plane_overlay_atomic_update(),<br /> overlay plane&amp;#39;s framebuffer pointer is NULL. So, dereferencing it would<br /> cause a kernel Oops(NULL pointer dereferencing). Fix the issue by<br /> disabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix warning when putting transaction with qgroups enabled after abort<br /> <br /> If we have a transaction abort with qgroups enabled we get a warning<br /> triggered when doing the final put on the transaction, like this:<br /> <br /> [552.6789] ------------[ cut here ]------------<br /> [552.6815] WARNING: CPU: 4 PID: 81745 at fs/btrfs/transaction.c:144 btrfs_put_transaction+0x123/0x130 [btrfs]<br /> [552.6817] Modules linked in: btrfs blake2b_generic xor (...)<br /> [552.6819] CPU: 4 PID: 81745 Comm: btrfs-transacti Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1<br /> [552.6819] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014<br /> [552.6819] RIP: 0010:btrfs_put_transaction+0x123/0x130 [btrfs]<br /> [552.6821] Code: bd a0 01 00 (...)<br /> [552.6821] RSP: 0018:ffffa168c0527e28 EFLAGS: 00010286<br /> [552.6821] RAX: ffff936042caed00 RBX: ffff93604a3eb448 RCX: 0000000000000000<br /> [552.6821] RDX: ffff93606421b028 RSI: ffffffff92ff0878 RDI: ffff93606421b010<br /> [552.6821] RBP: ffff93606421b000 R08: 0000000000000000 R09: ffffa168c0d07c20<br /> [552.6821] R10: 0000000000000000 R11: ffff93608dc52950 R12: ffffa168c0527e70<br /> [552.6821] R13: ffff93606421b000 R14: ffff93604a3eb420 R15: ffff93606421b028<br /> [552.6821] FS: 0000000000000000(0000) GS:ffff93675fb00000(0000) knlGS:0000000000000000<br /> [552.6821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [552.6821] CR2: 0000558ad262b000 CR3: 000000014feda005 CR4: 0000000000370ee0<br /> [552.6822] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [552.6822] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [552.6822] Call Trace:<br /> [552.6822] <br /> [552.6822] ? __warn+0x80/0x130<br /> [552.6822] ? btrfs_put_transaction+0x123/0x130 [btrfs]<br /> [552.6824] ? report_bug+0x1f4/0x200<br /> [552.6824] ? handle_bug+0x42/0x70<br /> [552.6824] ? exc_invalid_op+0x14/0x70<br /> [552.6824] ? asm_exc_invalid_op+0x16/0x20<br /> [552.6824] ? btrfs_put_transaction+0x123/0x130 [btrfs]<br /> [552.6826] btrfs_cleanup_transaction+0xe7/0x5e0 [btrfs]<br /> [552.6828] ? _raw_spin_unlock_irqrestore+0x23/0x40<br /> [552.6828] ? try_to_wake_up+0x94/0x5e0<br /> [552.6828] ? __pfx_process_timeout+0x10/0x10<br /> [552.6828] transaction_kthread+0x103/0x1d0 [btrfs]<br /> [552.6830] ? __pfx_transaction_kthread+0x10/0x10 [btrfs]<br /> [552.6832] kthread+0xee/0x120<br /> [552.6832] ? __pfx_kthread+0x10/0x10<br /> [552.6832] ret_from_fork+0x29/0x50<br /> [552.6832] <br /> [552.6832] ---[ end trace 0000000000000000 ]---<br /> <br /> This corresponds to this line of code:<br /> <br /> void btrfs_put_transaction(struct btrfs_transaction *transaction)<br /> {<br /> (...)<br /> WARN_ON(!RB_EMPTY_ROOT(<br /> &amp;transaction-&gt;delayed_refs.dirty_extent_root));<br /> (...)<br /> }<br /> <br /> The warning happens because btrfs_qgroup_destroy_extent_records(), called<br /> in the transaction abort path, we free all entries from the rbtree<br /> "dirty_extent_root" with rbtree_postorder_for_each_entry_safe(), but we<br /> don&amp;#39;t actually empty the rbtree - it&amp;#39;s still pointing to nodes that were<br /> freed.<br /> <br /> So set the rbtree&amp;#39;s root node to NULL to avoid this warning (assign<br /> RB_ROOT).

EDK2 contains a vulnerability in BIOS where an attacker may cause “Exposure of Sensitive Information to an Unauthorized Actor” by local access. Successful exploitation of this vulnerability will lead to <br /> <br /> possible information disclosure or escalation of privilege<br /> <br /> and impact Confidentiality.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8186: Fix use-after-free in driver remove path<br /> <br /> When devm runs function in the "remove" path for a device it runs them<br /> in the reverse order. That means that if you have parts of your driver<br /> that aren&amp;#39;t using devm or are using "roll your own" devm w/<br /> devm_add_action_or_reset() you need to keep that in mind.<br /> <br /> The mt8186 audio driver didn&amp;#39;t quite get this right. Specifically, in<br /> mt8186_init_clock() it called mt8186_audsys_clk_register() and then<br /> went on to call a bunch of other devm function. The caller of<br /> mt8186_init_clock() used devm_add_action_or_reset() to call<br /> mt8186_deinit_clock() but, because of the intervening devm functions,<br /> the order was wrong.<br /> <br /> Specifically at probe time, the order was:<br /> 1. mt8186_audsys_clk_register()<br /> 2. afe_priv-&gt;clk = devm_kcalloc(...)<br /> 3. afe_priv-&gt;clk[i] = devm_clk_get(...)<br /> <br /> At remove time, the order (which should have been 3, 2, 1) was:<br /> 1. mt8186_audsys_clk_unregister()<br /> 3. Free all of afe_priv-&gt;clk[i]<br /> 2. Free afe_priv-&gt;clk<br /> <br /> The above seemed to be causing a use-after-free. Luckily, it&amp;#39;s easy to<br /> fix this by simply using devm more correctly. Let&amp;#39;s move the<br /> devm_add_action_or_reset() to the right place. In addition to fixing<br /> the use-after-free, code inspection shows that this fixes a leak<br /> (missing call to mt8186_audsys_clk_unregister()) that would have<br /> happened if any of the syscon_regmap_lookup_by_phandle() calls in<br /> mt8186_init_clock() had failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver remove<br /> <br /> When the tagging protocol in current use is "ocelot-8021q" and we unbind<br /> the driver, we see this splat:<br /> <br /> $ echo &amp;#39;0000:00:00.2&amp;#39; &gt; /sys/bus/pci/drivers/fsl_enetc/unbind<br /> mscc_felix 0000:00:00.5 swp0: left promiscuous mode<br /> sja1105 spi2.0: Link is Down<br /> DSA: tree 1 torn down<br /> mscc_felix 0000:00:00.5 swp2: left promiscuous mode<br /> sja1105 spi2.2: Link is Down<br /> DSA: tree 3 torn down<br /> fsl_enetc 0000:00:00.2 eno2: left promiscuous mode<br /> mscc_felix 0000:00:00.5: Link is Down<br /> ------------[ cut here ]------------<br /> RTNL: assertion failed at net/dsa/tag_8021q.c (409)<br /> WARNING: CPU: 1 PID: 329 at net/dsa/tag_8021q.c:409 dsa_tag_8021q_unregister+0x12c/0x1a0<br /> Modules linked in:<br /> CPU: 1 PID: 329 Comm: bash Not tainted 6.5.0-rc3+ #771<br /> pc : dsa_tag_8021q_unregister+0x12c/0x1a0<br /> lr : dsa_tag_8021q_unregister+0x12c/0x1a0<br /> Call trace:<br /> dsa_tag_8021q_unregister+0x12c/0x1a0<br /> felix_tag_8021q_teardown+0x130/0x150<br /> felix_teardown+0x3c/0xd8<br /> dsa_tree_teardown_switches+0xbc/0xe0<br /> dsa_unregister_switch+0x168/0x260<br /> felix_pci_remove+0x30/0x60<br /> pci_device_remove+0x4c/0x100<br /> device_release_driver_internal+0x188/0x288<br /> device_links_unbind_consumers+0xfc/0x138<br /> device_release_driver_internal+0xe0/0x288<br /> device_driver_detach+0x24/0x38<br /> unbind_store+0xd8/0x108<br /> drv_attr_store+0x30/0x50<br /> ---[ end trace 0000000000000000 ]---<br /> ------------[ cut here ]------------<br /> RTNL: assertion failed at net/8021q/vlan_core.c (376)<br /> WARNING: CPU: 1 PID: 329 at net/8021q/vlan_core.c:376 vlan_vid_del+0x1b8/0x1f0<br /> CPU: 1 PID: 329 Comm: bash Tainted: G W 6.5.0-rc3+ #771<br /> pc : vlan_vid_del+0x1b8/0x1f0<br /> lr : vlan_vid_del+0x1b8/0x1f0<br /> dsa_tag_8021q_unregister+0x8c/0x1a0<br /> felix_tag_8021q_teardown+0x130/0x150<br /> felix_teardown+0x3c/0xd8<br /> dsa_tree_teardown_switches+0xbc/0xe0<br /> dsa_unregister_switch+0x168/0x260<br /> felix_pci_remove+0x30/0x60<br /> pci_device_remove+0x4c/0x100<br /> device_release_driver_internal+0x188/0x288<br /> device_links_unbind_consumers+0xfc/0x138<br /> device_release_driver_internal+0xe0/0x288<br /> device_driver_detach+0x24/0x38<br /> unbind_store+0xd8/0x108<br /> drv_attr_store+0x30/0x50<br /> DSA: tree 0 torn down<br /> <br /> This was somewhat not so easy to spot, because "ocelot-8021q" is not the<br /> default tagging protocol, and thus, not everyone who tests the unbinding<br /> path may have switched to it beforehand. The default<br /> felix_tag_npi_teardown() does not require rtnl_lock() to be held.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of: overlay: Call of_changeset_init() early<br /> <br /> When of_overlay_fdt_apply() fails, the changeset may be partially<br /> applied, and the caller is still expected to call of_overlay_remove() to<br /> clean up this partial state.<br /> <br /> However, of_overlay_apply() calls of_resolve_phandles() before<br /> init_overlay_changeset(). Hence if the overlay fails to apply due to an<br /> unresolved symbol, the overlay_changeset.cset.entries list is still<br /> uninitialized, and cleanup will crash with a NULL-pointer dereference in<br /> overlay_removal_is_ok().<br /> <br /> Fix this by moving the call to of_changeset_init() from<br /> init_overlay_changeset() to of_overlay_fdt_apply(), where all other<br /> early initialization is done.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: bpf_sk_storage: Fix invalid wait context lockdep report<br /> <br /> &amp;#39;./test_progs -t test_local_storage&amp;#39; reported a splat:<br /> <br /> [ 27.137569] =============================<br /> [ 27.138122] [ BUG: Invalid wait context ]<br /> [ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O<br /> [ 27.139542] -----------------------------<br /> [ 27.140106] test_progs/1729 is trying to lock:<br /> [ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130<br /> [ 27.141834] other info that might help us debug this:<br /> [ 27.142437] context-{5:5}<br /> [ 27.142856] 2 locks held by test_progs/1729:<br /> [ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40<br /> [ 27.144492] #1: ffff888107deb2c0 (&amp;storage-&gt;lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0<br /> [ 27.145855] stack backtrace:<br /> [ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247<br /> [ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 27.149127] Call Trace:<br /> [ 27.149490] <br /> [ 27.149867] dump_stack_lvl+0x130/0x1d0<br /> [ 27.152609] dump_stack+0x14/0x20<br /> [ 27.153131] __lock_acquire+0x1657/0x2220<br /> [ 27.153677] lock_acquire+0x1b8/0x510<br /> [ 27.157908] local_lock_acquire+0x29/0x130<br /> [ 27.159048] obj_cgroup_charge+0xf4/0x3c0<br /> [ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0<br /> [ 27.161931] __kmem_cache_alloc_node+0x51/0x210<br /> [ 27.163557] __kmalloc+0xaa/0x210<br /> [ 27.164593] bpf_map_kzalloc+0xbc/0x170<br /> [ 27.165147] bpf_selem_alloc+0x130/0x510<br /> [ 27.166295] bpf_local_storage_update+0x5aa/0x8e0<br /> [ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0<br /> [ 27.169199] bpf_map_update_value+0x415/0x4f0<br /> [ 27.169871] map_update_elem+0x413/0x550<br /> [ 27.170330] __sys_bpf+0x5e9/0x640<br /> [ 27.174065] __x64_sys_bpf+0x80/0x90<br /> [ 27.174568] do_syscall_64+0x48/0xa0<br /> [ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 27.175932] RIP: 0033:0x7effb40e41ad<br /> [ 27.176357] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d8<br /> [ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141<br /> [ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad<br /> [ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002<br /> [ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788<br /> [ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000<br /> [ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000<br /> [ 27.184958] <br /> <br /> It complains about acquiring a local_lock while holding a raw_spin_lock.<br /> It means it should not allocate memory while holding a raw_spin_lock<br /> since it is not safe for RT.<br /> <br /> raw_spin_lock is needed because bpf_local_storage supports tracing<br /> context. In particular for task local storage, it is easy to<br /> get a "current" task PTR_TO_BTF_ID in tracing bpf prog.<br /> However, task (and cgroup) local storage has already been moved to<br /> bpf mem allocator which can be used after raw_spin_lock.<br /> <br /> The splat is for the sk storage. For sk (and inode) storage,<br /> it has not been moved to bpf mem allocator. Using raw_spin_lock or not,<br /> kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context.<br /> However, the local storage helper requires a verifier accepted<br /> sk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean running<br /> a bpf prog in a kzalloc unsafe context and also able to hold a verifier<br /> accepted sk pointer) could happen.<br /> <br /> This patch avoids kzalloc after raw_spin_lock to silent the splat.<br /> There is an existing kzalloc before the raw_spin_lock. At that point,<br /> a kzalloc is very likely required because a lookup has just been done<br /> before. Thus, this patch always does the kzalloc before acq<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of error<br /> <br /> If clk_get_rate() fails, the clk that has just been allocated needs to be<br /> freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/idle: mark arch_cpu_idle() noinstr<br /> <br /> linux-next commit ("cpuidle: tracing: Warn about !rcu_is_watching()")<br /> adds a new warning which hits on s390&amp;#39;s arch_cpu_idle() function:<br /> <br /> RCU not on for: arch_cpu_idle+0x0/0x28<br /> WARNING: CPU: 2 PID: 0 at include/linux/trace_recursion.h:162 arch_ftrace_ops_list_func+0x24c/0x258<br /> Modules linked in:<br /> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.2.0-rc6-next-20230202 #4<br /> Hardware name: IBM 8561 T01 703 (z/VM 7.3.0)<br /> Krnl PSW : 0404d00180000000 00000000002b55c0 (arch_ftrace_ops_list_func+0x250/0x258)<br /> R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3<br /> Krnl GPRS: c0000000ffffbfff 0000000080000002 0000000000000026 0000000000000000<br /> 0000037ffffe3a28 0000037ffffe3a20 0000000000000000 0000000000000000<br /> 0000000000000000 0000000000f4acf6 00000000001044f0 0000037ffffe3cb0<br /> 0000000000000000 0000000000000000 00000000002b55bc 0000037ffffe3bb8<br /> Krnl Code: 00000000002b55b0: c02000840051 larl %r2,0000000001335652<br /> 00000000002b55b6: c0e5fff512d1 brasl %r14,0000000000157b58<br /> #00000000002b55bc: af000000 mc 0,0<br /> &gt;00000000002b55c0: a7f4ffe7 brc 15,00000000002b558e<br /> 00000000002b55c4: 0707 bcr 0,%r7<br /> 00000000002b55c6: 0707 bcr 0,%r7<br /> 00000000002b55c8: eb6ff0480024 stmg %r6,%r15,72(%r15)<br /> 00000000002b55ce: b90400ef lgr %r14,%r15<br /> Call Trace:<br /> [] arch_ftrace_ops_list_func+0x250/0x258<br /> ([] arch_ftrace_ops_list_func+0x24c/0x258)<br /> [] ftrace_common+0x1c/0x20<br /> [] arch_cpu_idle+0x6/0x28<br /> [] default_idle_call+0x76/0x128<br /> [] do_idle+0xf4/0x1b0<br /> [] cpu_startup_entry+0x36/0x40<br /> [] smp_start_secondary+0x140/0x150<br /> [] restart_int_handler+0x6e/0x90<br /> <br /> Mark arch_cpu_idle() noinstr like all other architectures with<br /> CONFIG_ARCH_WANTS_NO_INSTR (should) have it to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: don&amp;#39;t attempt to queue IO under RCU protection<br /> <br /> dm looks up the table for IO based on the request type, with an<br /> assumption that if the request is marked REQ_NOWAIT, it&amp;#39;s fine to<br /> attempt to submit that IO while under RCU read lock protection. This<br /> is not OK, as REQ_NOWAIT just means that we should not be sleeping<br /> waiting on other IO, it does not mean that we can&amp;#39;t potentially<br /> schedule.<br /> <br /> A simple test case demonstrates this quite nicely:<br /> <br /> int main(int argc, char *argv[])<br /> {<br /> struct iovec iov;<br /> int fd;<br /> <br /> fd = open("/dev/dm-0", O_RDONLY | O_DIRECT);<br /> posix_memalign(&amp;iov.iov_base, 4096, 4096);<br /> iov.iov_len = 4096;<br /> preadv2(fd, &amp;iov, 1, 0, RWF_NOWAIT);<br /> return 0;<br /> }<br /> <br /> which will instantly spew:<br /> <br /> BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306<br /> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm-nowait<br /> preempt_count: 0, expected: 0<br /> RCU nest depth: 1, expected: 0<br /> INFO: lockdep is turned off.<br /> CPU: 7 PID: 5580 Comm: dm-nowait Not tainted 6.6.0-rc1-g39956d2dcd81 #132<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x11d/0x1b0<br /> __might_resched+0x3c3/0x5e0<br /> ? preempt_count_sub+0x150/0x150<br /> mempool_alloc+0x1e2/0x390<br /> ? mempool_resize+0x7d0/0x7d0<br /> ? lock_sync+0x190/0x190<br /> ? lock_release+0x4b7/0x670<br /> ? internal_get_user_pages_fast+0x868/0x2d40<br /> bio_alloc_bioset+0x417/0x8c0<br /> ? bvec_alloc+0x200/0x200<br /> ? internal_get_user_pages_fast+0xb8c/0x2d40<br /> bio_alloc_clone+0x53/0x100<br /> dm_submit_bio+0x27f/0x1a20<br /> ? lock_release+0x4b7/0x670<br /> ? blk_try_enter_queue+0x1a0/0x4d0<br /> ? dm_dax_direct_access+0x260/0x260<br /> ? rcu_is_watching+0x12/0xb0<br /> ? blk_try_enter_queue+0x1cc/0x4d0<br /> __submit_bio+0x239/0x310<br /> ? __bio_queue_enter+0x700/0x700<br /> ? kvm_clock_get_cycles+0x40/0x60<br /> ? ktime_get+0x285/0x470<br /> submit_bio_noacct_nocheck+0x4d9/0xb80<br /> ? should_fail_request+0x80/0x80<br /> ? preempt_count_sub+0x150/0x150<br /> ? lock_release+0x4b7/0x670<br /> ? __bio_add_page+0x143/0x2d0<br /> ? iov_iter_revert+0x27/0x360<br /> submit_bio_noacct+0x53e/0x1b30<br /> submit_bio_wait+0x10a/0x230<br /> ? submit_bio_wait_endio+0x40/0x40<br /> __blkdev_direct_IO_simple+0x4f8/0x780<br /> ? blkdev_bio_end_io+0x4c0/0x4c0<br /> ? stack_trace_save+0x90/0xc0<br /> ? __bio_clone+0x3c0/0x3c0<br /> ? lock_release+0x4b7/0x670<br /> ? lock_sync+0x190/0x190<br /> ? atime_needs_update+0x3bf/0x7e0<br /> ? timestamp_truncate+0x21b/0x2d0<br /> ? inode_owner_or_capable+0x240/0x240<br /> blkdev_direct_IO.part.0+0x84a/0x1810<br /> ? rcu_is_watching+0x12/0xb0<br /> ? lock_release+0x4b7/0x670<br /> ? blkdev_read_iter+0x40d/0x530<br /> ? reacquire_held_locks+0x4e0/0x4e0<br /> ? __blkdev_direct_IO_simple+0x780/0x780<br /> ? rcu_is_watching+0x12/0xb0<br /> ? __mark_inode_dirty+0x297/0xd50<br /> ? preempt_count_add+0x72/0x140<br /> blkdev_read_iter+0x2a4/0x530<br /> do_iter_readv_writev+0x2f2/0x3c0<br /> ? generic_copy_file_range+0x1d0/0x1d0<br /> ? fsnotify_perm.part.0+0x25d/0x630<br /> ? security_file_permission+0xd8/0x100<br /> do_iter_read+0x31b/0x880<br /> ? import_iovec+0x10b/0x140<br /> vfs_readv+0x12d/0x1a0<br /> ? vfs_iter_read+0xb0/0xb0<br /> ? rcu_is_watching+0x12/0xb0<br /> ? rcu_is_watching+0x12/0xb0<br /> ? lock_release+0x4b7/0x670<br /> do_preadv+0x1b3/0x260<br /> ? do_readv+0x370/0x370<br /> __x64_sys_preadv2+0xef/0x150<br /> do_syscall_64+0x39/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f5af41ad806<br /> Code: 41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45 89 c1 49 89 ca 45 31 c0 b8 47 01 00 00 0f 05 3d 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d da 55<br /> RSP: 002b:00007ffd3145c7f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000147<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5af41ad806<br /> RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003<br /> RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003<br /> R13: 00007ffd3145c850 R14: 000055f5f0431dd8 R15: 0000000000000001<br /> <br /> <br /> where in fact it is<br /> ---truncated---