Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak<br /> <br /> syzbot identified a kernel information leak vulnerability in<br /> do_sys_name_to_handle() and issued the following report [1].<br /> <br /> [1]<br /> "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40<br /> instrument_copy_to_user include/linux/instrumented.h:114 [inline]<br /> _copy_to_user+0xbc/0x100 lib/usercopy.c:40<br /> copy_to_user include/linux/uaccess.h:191 [inline]<br /> do_sys_name_to_handle fs/fhandle.c:73 [inline]<br /> __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]<br /> __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94<br /> __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94<br /> ...<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768<br /> slab_alloc_node mm/slub.c:3478 [inline]<br /> __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517<br /> __do_kmalloc_node mm/slab_common.c:1006 [inline]<br /> __kmalloc+0x121/0x3c0 mm/slab_common.c:1020<br /> kmalloc include/linux/slab.h:604 [inline]<br /> do_sys_name_to_handle fs/fhandle.c:39 [inline]<br /> __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]<br /> __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94<br /> __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94<br /> ...<br /> <br /> Bytes 18-19 of 20 are uninitialized<br /> Memory access of size 20 starts at ffff888128a46380<br /> Data copied to user address 0000000020000240"<br /> <br /> Per Chuck Lever&amp;#39;s suggestion, use kzalloc() instead of kmalloc() to<br /> solve the problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete<br /> <br /> The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data<br /> structures have been fully initialised by the time it runs. However, because of<br /> the order in which things are initialised, this is not guaranteed to be the<br /> case, because the device is exposed to the USB subsystem before the ath9k driver<br /> initialisation is completed.<br /> <br /> We already committed a partial fix for this in commit:<br /> 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()")<br /> <br /> However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event<br /> tasklet, pairing it with an "initialisation complete" bit in the TX struct. It<br /> seems syzbot managed to trigger the race for one of the other commands as well,<br /> so let&amp;#39;s just move the existing synchronisation bit to cover the whole<br /> tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside<br /> ath9k_tx_init()).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: adv7511: fix crash on irq during probe<br /> <br /> Moved IRQ registration down to end of adv7511_probe().<br /> <br /> If an IRQ already is pending during adv7511_probe<br /> (before adv7511_cec_init) then cec_received_msg_ts<br /> could crash using uninitialized data:<br /> <br /> Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5<br /> Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP<br /> Call trace:<br /> cec_received_msg_ts+0x48/0x990 [cec]<br /> adv7511_cec_irq_process+0x1cc/0x308 [adv7511]<br /> adv7511_irq_process+0xd8/0x120 [adv7511]<br /> adv7511_irq_handler+0x1c/0x30 [adv7511]<br /> irq_thread_fn+0x30/0xa0<br /> irq_thread+0x14c/0x238<br /> kthread+0x190/0x1a8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: Fix potential NULL pointer dereference<br /> <br /> Below race may cause NULL pointer dereference<br /> <br /> P1 P2<br /> dquot_free_inode quota_off<br /> drop_dquot_ref<br /> remove_dquot_ref<br /> dquots = i_dquot(inode)<br /> dquots = i_dquot(inode)<br /> srcu_read_lock<br /> dquots[cnt]) != NULL (1)<br /> dquots[type] = NULL (2)<br /> spin_lock(&amp;dquots[cnt]-&gt;dq_dqb_lock) (3)<br /> ....<br /> <br /> If dquot_free_inode(or other routines) checks inode&amp;#39;s quota pointers (1)<br /> before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer<br /> dereference will be triggered.<br /> <br /> So let&amp;#39;s fix it by using a temporary pointer to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: meson: Add missing clocks to axg_clk_regmaps<br /> <br /> Some clocks were missing from axg_clk_regmaps, which caused kernel panic<br /> during cat /sys/kernel/debug/clk/clk_summary<br /> <br /> [ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc<br /> ...<br /> [ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 57.436900] pc : regmap_read+0x1c/0x88<br /> [ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0<br /> [ 57.445611] sp : ffff800082f1b690<br /> [ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70<br /> [ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000<br /> [ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000<br /> [ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff<br /> [ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000<br /> [ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100<br /> [ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24<br /> [ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710<br /> [ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000<br /> [ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000<br /> [ 57.519615] Call trace:<br /> [ 57.522030] regmap_read+0x1c/0x88<br /> [ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0<br /> [ 57.530050] clk_core_is_enabled+0x44/0x120<br /> [ 57.534190] clk_summary_show_subtree+0x154/0x2f0<br /> [ 57.538847] clk_summary_show_subtree+0x220/0x2f0<br /> [ 57.543505] clk_summary_show_subtree+0x220/0x2f0<br /> [ 57.548162] clk_summary_show_subtree+0x220/0x2f0<br /> [ 57.552820] clk_summary_show_subtree+0x220/0x2f0<br /> [ 57.557477] clk_summary_show_subtree+0x220/0x2f0<br /> [ 57.562135] clk_summary_show_subtree+0x220/0x2f0<br /> [ 57.566792] clk_summary_show_subtree+0x220/0x2f0<br /> [ 57.571450] clk_summary_show+0x84/0xb8<br /> [ 57.575245] seq_read_iter+0x1bc/0x4b8<br /> [ 57.578954] seq_read+0x8c/0xd0<br /> [ 57.582059] full_proxy_read+0x68/0xc8<br /> [ 57.585767] vfs_read+0xb0/0x268<br /> [ 57.588959] ksys_read+0x70/0x108<br /> [ 57.592236] __arm64_sys_read+0x24/0x38<br /> [ 57.596031] invoke_syscall+0x50/0x128<br /> [ 57.599740] el0_svc_common.constprop.0+0x48/0xf8<br /> [ 57.604397] do_el0_svc+0x28/0x40<br /> [ 57.607675] el0_svc+0x34/0xb8<br /> [ 57.610694] el0t_64_sync_handler+0x13c/0x158<br /> [ 57.615006] el0t_64_sync+0x190/0x198<br /> [ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)<br /> [ 57.624668] ---[ end trace 0000000000000000 ]---<br /> <br /> [jbrunet: add missing Fixes tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> packet: annotate data-races around ignore_outgoing<br /> <br /> ignore_outgoing is read locklessly from dev_queue_xmit_nit()<br /> and packet_getsockopt()<br /> <br /> Add appropriate READ_ONCE()/WRITE_ONCE() annotations.<br /> <br /> syzbot reported:<br /> <br /> BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt<br /> <br /> write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:<br /> packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003<br /> do_sock_setsockopt net/socket.c:2311 [inline]<br /> __sys_setsockopt+0x1d8/0x250 net/socket.c:2334<br /> __do_sys_setsockopt net/socket.c:2343 [inline]<br /> __se_sys_setsockopt net/socket.c:2340 [inline]<br /> __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340<br /> do_syscall_64+0xd3/0x1d0<br /> entry_SYSCALL_64_after_hwframe+0x6d/0x75<br /> <br /> read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:<br /> dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248<br /> xmit_one net/core/dev.c:3527 [inline]<br /> dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547<br /> __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335<br /> dev_queue_xmit include/linux/netdevice.h:3091 [inline]<br /> batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108<br /> batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127<br /> batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]<br /> batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]<br /> batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700<br /> process_one_work kernel/workqueue.c:3254 [inline]<br /> process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335<br /> worker_thread+0x526/0x730 kernel/workqueue.c:3416<br /> kthread+0x1d1/0x210 kernel/kthread.c:388<br /> ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243<br /> <br /> value changed: 0x00 -&gt; 0x01<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G W 6.8.0-syzkaller-08073-g480e035fc4c7 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024<br /> Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hsr: Fix uninit-value access in hsr_get_node()<br /> <br /> KMSAN reported the following uninit-value access issue [1]:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246<br /> hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246<br /> fill_frame_info net/hsr/hsr_forward.c:577 [inline]<br /> hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615<br /> hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223<br /> __netdev_start_xmit include/linux/netdevice.h:4940 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4954 [inline]<br /> xmit_one net/core/dev.c:3548 [inline]<br /> dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564<br /> __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349<br /> dev_queue_xmit include/linux/netdevice.h:3134 [inline]<br /> packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276<br /> packet_snd net/packet/af_packet.c:3087 [inline]<br /> packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> __sys_sendto+0x735/0xa10 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768<br /> slab_alloc_node mm/slub.c:3478 [inline]<br /> kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523<br /> kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560<br /> __alloc_skb+0x318/0x740 net/core/skbuff.c:651<br /> alloc_skb include/linux/skbuff.h:1286 [inline]<br /> alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334<br /> sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787<br /> packet_alloc_skb net/packet/af_packet.c:2936 [inline]<br /> packet_snd net/packet/af_packet.c:3030 [inline]<br /> packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg net/socket.c:745 [inline]<br /> __sys_sendto+0x735/0xa10 net/socket.c:2191<br /> __do_sys_sendto net/socket.c:2203 [inline]<br /> __se_sys_sendto net/socket.c:2199 [inline]<br /> __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b<br /> <br /> CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023<br /> =====================================================<br /> <br /> If the packet type ID field in the Ethernet header is either ETH_P_PRP or<br /> ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()<br /> reads an invalid value as a sequence number. This causes the above issue.<br /> <br /> This patch fixes the issue by returning NULL if the Ethernet header is not<br /> followed by an HSR tag.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Fix refcnt handling in __inet_hash_connect().<br /> <br /> syzbot reported a warning in sk_nulls_del_node_init_rcu().<br /> <br /> The commit 66b60b0c8c4a ("dccp/tcp: Unhash sk from ehash for tb2 alloc<br /> failure after check_estalblished().") tried to fix an issue that an<br /> unconnected socket occupies an ehash entry when bhash2 allocation fails.<br /> <br /> In such a case, we need to revert changes done by check_established(),<br /> which does not hold refcnt when inserting socket into ehash.<br /> <br /> So, to revert the change, we need to __sk_nulls_add_node_rcu() instead<br /> of sk_nulls_add_node_rcu().<br /> <br /> Otherwise, sock_put() will cause refcnt underflow and leak the socket.<br /> <br /> [0]:<br /> WARNING: CPU: 0 PID: 23948 at include/net/sock.h:799 sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799<br /> Modules linked in:<br /> CPU: 0 PID: 23948 Comm: syz-executor.2 Not tainted 6.8.0-rc6-syzkaller-00159-gc055fc00c07b #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024<br /> RIP: 0010:sk_nulls_del_node_init_rcu+0x166/0x1a0 include/net/sock.h:799<br /> Code: e8 7f 71 c6 f7 83 fb 02 7c 25 e8 35 6d c6 f7 4d 85 f6 0f 95 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 1b 6d c6 f7 90 0b 90 eb b2 e8 10 6d c6 f7 4c 89 e7 be 04 00 00 00 e8 63 e7 d2<br /> RSP: 0018:ffffc900032d7848 EFLAGS: 00010246<br /> RAX: ffffffff89cd0035 RBX: 0000000000000001 RCX: 0000000000040000<br /> RDX: ffffc90004de1000 RSI: 000000000003ffff RDI: 0000000000040000<br /> RBP: 1ffff1100439ac26 R08: ffffffff89ccffe3 R09: 1ffff1100439ac28<br /> R10: dffffc0000000000 R11: ffffed100439ac29 R12: ffff888021cd6140<br /> R13: dffffc0000000000 R14: ffff88802a9bf5c0 R15: ffff888021cd6130<br /> FS: 00007f3b823f16c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f3b823f0ff8 CR3: 000000004674a000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __inet_hash_connect+0x140f/0x20b0 net/ipv4/inet_hashtables.c:1139<br /> dccp_v6_connect+0xcb9/0x1480 net/dccp/ipv6.c:956<br /> __inet_stream_connect+0x262/0xf30 net/ipv4/af_inet.c:678<br /> inet_stream_connect+0x65/0xa0 net/ipv4/af_inet.c:749<br /> __sys_connect_file net/socket.c:2048 [inline]<br /> __sys_connect+0x2df/0x310 net/socket.c:2065<br /> __do_sys_connect net/socket.c:2075 [inline]<br /> __se_sys_connect net/socket.c:2072 [inline]<br /> __x64_sys_connect+0x7a/0x90 net/socket.c:2072<br /> do_syscall_64+0xf9/0x240<br /> entry_SYSCALL_64_after_hwframe+0x6f/0x77<br /> RIP: 0033:0x7f3b8167dda9<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 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 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f3b823f10c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002a<br /> RAX: ffffffffffffffda RBX: 00007f3b817abf80 RCX: 00007f3b8167dda9<br /> RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003<br /> RBP: 00007f3b823f1120 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 000000000000000b R14: 00007f3b817abf80 R15: 00007ffd3beb57b8<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rds: tcp: Fix use-after-free of net in reqsk_timer_handler().<br /> <br /> syzkaller reported a warning of netns tracker [0] followed by KASAN<br /> splat [1] and another ref tracker warning [1].<br /> <br /> syzkaller could not find a repro, but in the log, the only suspicious<br /> sequence was as follows:<br /> <br /> 18:26:22 executing program 1:<br /> r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)<br /> ...<br /> connect$inet6(r0, &amp;(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)<br /> <br /> The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.<br /> <br /> So, the scenario would be:<br /> <br /> 1. unshare(CLONE_NEWNET) creates a per netns tcp listener in<br /> rds_tcp_listen_init().<br /> 2. syz-executor connect()s to it and creates a reqsk.<br /> 3. syz-executor exit()s immediately.<br /> 4. netns is dismantled. [0]<br /> 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1]<br /> 6. listener is freed after RCU grace period. [2]<br /> <br /> Basically, reqsk assumes that the listener guarantees netns safety<br /> until all reqsk timers are expired by holding the listener&amp;#39;s refcount.<br /> However, this was not the case for kernel sockets.<br /> <br /> Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener&amp;#39;s reqsk in<br /> inet_twsk_purge()") fixed this issue only for per-netns ehash.<br /> <br /> Let&amp;#39;s apply the same fix for the global ehash.<br /> <br /> [0]:<br /> ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at<br /> sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)<br /> inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)<br /> __sock_create (net/socket.c:1572)<br /> rds_tcp_listen_init (net/rds/tcp_listen.c:279)<br /> rds_tcp_init_net (net/rds/tcp.c:577)<br /> ops_init (net/core/net_namespace.c:137)<br /> setup_net (net/core/net_namespace.c:340)<br /> copy_net_ns (net/core/net_namespace.c:497)<br /> create_new_namespaces (kernel/nsproxy.c:110)<br /> unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))<br /> ksys_unshare (kernel/fork.c:3429)<br /> __x64_sys_unshare (kernel/fork.c:3496)<br /> do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)<br /> ...<br /> WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)<br /> <br /> [1]:<br /> BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)<br /> Read of size 8 at addr ffff88801b370400 by task swapper/0/0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))<br /> print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)<br /> kasan_report (mm/kasan/report.c:603)<br /> inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966)<br /> reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)<br /> call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)<br /> __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)<br /> run_timer_softirq (kernel/time/timer.c:2053)<br /> __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554)<br /> irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))<br /> <br /> <br /> Allocated by task 258 on cpu 0 at 83.612050s:<br /> kasan_save_stack (mm/kasan/common.c:48)<br /> kasan_save_track (mm/kasan/common.c:68)<br /> __kasan_slab_alloc (mm/kasan/common.c:343)<br /> kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)<br /> copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)<br /> create_new_namespaces (kernel/nsproxy.c:110)<br /> unshare_nsproxy_name<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: lpspi: Avoid potential use-after-free in probe()<br /> <br /> fsl_lpspi_probe() is allocating/disposing memory manually with<br /> spi_alloc_host()/spi_alloc_target(), but uses<br /> devm_spi_register_controller(). In case of error after the latter call the<br /> memory will be explicitly freed in the probe function by<br /> spi_controller_put() call, but used afterwards by "devm" management outside<br /> probe() (spi_unregister_controller()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: comedi_8255: Correct error in subdevice initialization<br /> <br /> The refactoring done in commit 5c57b1ccecc7 ("comedi: comedi_8255: Rework<br /> subdevice initialization functions") to the initialization of the io<br /> field of struct subdev_8255_private broke all cards using the<br /> drivers/comedi/drivers/comedi_8255.c module.<br /> <br /> Prior to 5c57b1ccecc7, __subdev_8255_init() initialized the io field<br /> in the newly allocated struct subdev_8255_private to the non-NULL<br /> callback given to the function, otherwise it used a flag parameter to<br /> select between subdev_8255_mmio and subdev_8255_io. The refactoring<br /> removed that logic and the flag, as subdev_8255_mm_init() and<br /> subdev_8255_io_init() now explicitly pass subdev_8255_mmio and<br /> subdev_8255_io respectively to __subdev_8255_init(), only<br /> __subdev_8255_init() never sets spriv-&gt;io to the supplied<br /> callback. That spriv-&gt;io is NULL leads to a later BUG:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: 0010 [#1] SMP PTI<br /> CPU: 1 PID: 1210 Comm: systemd-udevd Not tainted 6.7.3-x86_64 #1<br /> Hardware name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b<br /> RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00<br /> RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001<br /> R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000<br /> R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8<br /> FS: 00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0<br /> Call Trace:<br /> <br /> ? __die_body+0x15/0x57<br /> ? page_fault_oops+0x2ef/0x33c<br /> ? insert_vmap_area.constprop.0+0xb6/0xd5<br /> ? alloc_vmap_area+0x529/0x5ee<br /> ? exc_page_fault+0x15a/0x489<br /> ? asm_exc_page_fault+0x22/0x30<br /> __subdev_8255_init+0x79/0x8d [comedi_8255]<br /> pci_8255_auto_attach+0x11a/0x139 [8255_pci]<br /> comedi_auto_config+0xac/0x117 [comedi]<br /> ? __pfx___driver_attach+0x10/0x10<br /> pci_device_probe+0x88/0xf9<br /> really_probe+0x101/0x248<br /> __driver_probe_device+0xbb/0xed<br /> driver_probe_device+0x1a/0x72<br /> __driver_attach+0xd4/0xed<br /> bus_for_each_dev+0x76/0xb8<br /> bus_add_driver+0xbe/0x1be<br /> driver_register+0x9a/0xd8<br /> comedi_pci_driver_register+0x28/0x48 [comedi_pci]<br /> ? __pfx_pci_8255_driver_init+0x10/0x10 [8255_pci]<br /> do_one_initcall+0x72/0x183<br /> do_init_module+0x5b/0x1e8<br /> init_module_from_file+0x86/0xac<br /> __do_sys_finit_module+0x151/0x218<br /> do_syscall_64+0x72/0xdb<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> RIP: 0033:0x7f72f50a0cb9<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 0d 47 71 0c 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffd47e512d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139<br /> RAX: ffffffffffffffda RBX: 0000562dd06ae070 RCX: 00007f72f50a0cb9<br /> RDX: 0000000000000000 RSI: 00007f72f52d32df RDI: 000000000000000e<br /> RBP: 0000000000000000 R08: 00007f72f5168b20 R09: 0000000000000000<br /> R10: 0000000000000050 R11: 0000000000000246 R12: 00007f72f52d32df<br /> R13: 0000000000020000 R14: 0000562dd06785c0 R15: 0000562dcfd0e9a8<br /> <br /> Modules linked in: 8255_pci(+) comedi_8255 comedi_pci comedi intel_gtt e100(+) acpi_cpufreq rtc_cmos usbhid<br /> CR2: 0000000000000000<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b<br /> RDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00<br /> RBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001<br /> R10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000<br /> R13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8<br /> FS: <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: fix panic when nfs4_ff_layout_prepare_ds() fails<br /> <br /> We&amp;#39;ve been seeing the following panic in production<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000065<br /> PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0<br /> RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]<br /> Call Trace:<br /> <br /> ? __die+0x78/0xc0<br /> ? page_fault_oops+0x286/0x380<br /> ? __rpc_execute+0x2c3/0x470 [sunrpc]<br /> ? rpc_new_task+0x42/0x1c0 [sunrpc]<br /> ? exc_page_fault+0x5d/0x110<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]<br /> ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]<br /> ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles]<br /> pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4]<br /> pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4]<br /> ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles]<br /> nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles]<br /> ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles]<br /> __nfs_pageio_add_request+0x154/0x6c0 [nfs]<br /> nfs_pageio_add_request+0x26b/0x380 [nfs]<br /> nfs_do_writepage+0x111/0x1e0 [nfs]<br /> nfs_writepages_callback+0xf/0x30 [nfs]<br /> write_cache_pages+0x17f/0x380<br /> ? nfs_pageio_init_write+0x50/0x50 [nfs]<br /> ? nfs_writepages+0x6d/0x210 [nfs]<br /> ? nfs_writepages+0x6d/0x210 [nfs]<br /> nfs_writepages+0x125/0x210 [nfs]<br /> do_writepages+0x67/0x220<br /> ? generic_perform_write+0x14b/0x210<br /> filemap_fdatawrite_wbc+0x5b/0x80<br /> file_write_and_wait_range+0x6d/0xc0<br /> nfs_file_fsync+0x81/0x170 [nfs]<br /> ? nfs_file_mmap+0x60/0x60 [nfs]<br /> __x64_sys_fsync+0x53/0x90<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Inspecting the core with drgn I was able to pull this<br /> <br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0]<br /> #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27<br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0][&amp;#39;idx&amp;#39;]<br /> (u32)1<br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0][&amp;#39;flseg&amp;#39;].mirror_array[1].mirror_ds<br /> (struct nfs4_ff_layout_ds *)0xffffffffffffffed<br /> <br /> This is clear from the stack trace, we call nfs4_ff_layout_prepare_ds()<br /> which could error out initializing the mirror_ds, and then we go to<br /> clean it all up and our check is only for if (!mirror-&gt;mirror_ds). This<br /> is inconsistent with the rest of the users of mirror_ds, which have<br /> <br /> if (IS_ERR_OR_NULL(mirror_ds))<br /> <br /> to keep from tripping over this exact scenario. Fix this up in<br /> ff_layout_cancel_io() to make sure we don&amp;#39;t panic when we get an error.<br /> I also spot checked all the other instances of checking mirror_ds and we<br /> appear to be doing the correct checks everywhere, only unconditionally<br /> dereferencing mirror_ds when we know it would be valid.