Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it<br /> <br /> Wakeup for IRQ1 should be disabled only in cases where i8042 had<br /> actually enabled it, otherwise "wake_depth" for this IRQ will try to<br /> drop below zero and there will be an unpleasant WARN() logged:<br /> <br /> kernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug<br /> kernel: ------------[ cut here ]------------<br /> kernel: Unbalanced IRQ 1 wake disable<br /> kernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0<br /> <br /> The PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops<br /> which sets amd_pmc_suspend_handler() to the .suspend, .freeze, and<br /> .poweroff handlers. i8042_pm_suspend(), however, is only set as<br /> the .suspend handler.<br /> <br /> Fix the issue by call PMC suspend handler only from the same set of<br /> dev_pm_ops handlers as i8042_pm_suspend(), which currently means just<br /> the .suspend handler.<br /> <br /> To reproduce this issue try hibernating (S4) the machine after a fresh boot<br /> without putting it into s2idle first.<br /> <br /> [ij: edited the commit message.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: clamp maximum hashtable size to INT_MAX<br /> <br /> Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it<br /> is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when<br /> resizing hashtable because __GFP_NOWARN is unset. See:<br /> <br /> 0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")<br /> <br /> Note: hashtable resize is only possible from init_netns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The per-netns structure can be obtained from the table-&gt;data using<br /> container_of(), then the &amp;#39;net&amp;#39; one can be retrieved from the listen<br /> socket (if available).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: plpmtud_probe_interval: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, as this is the only<br /> member needed from the &amp;#39;net&amp;#39; structure, but that would increase the size<br /> of this fix, to use &amp;#39;*data&amp;#39; everywhere &amp;#39;net-&gt;sctp.probe_interval&amp;#39; is<br /> used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: udp_port: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, but that would<br /> increase the size of this fix, while &amp;#39;sctp.ctl_sock&amp;#39; still needs to be<br /> retrieved from &amp;#39;net&amp;#39; structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: auth_enable: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, but that would<br /> increase the size of this fix, while &amp;#39;sctp.ctl_sock&amp;#39; still needs to be<br /> retrieved from &amp;#39;net&amp;#39; structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: rto_min/max: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, as this is the only<br /> member needed from the &amp;#39;net&amp;#39; structure, but that would increase the size<br /> of this fix, to use &amp;#39;*data&amp;#39; everywhere &amp;#39;net-&gt;sctp.rto_min/max&amp;#39; is used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: sysctl: cookie_hmac_alg: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in a previous commit of this series, using the &amp;#39;net&amp;#39;<br /> structure via &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;net&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().<br /> <br /> Note that table-&gt;data could also be used directly, as this is the only<br /> member needed from the &amp;#39;net&amp;#39; structure, but that would increase the size<br /> of this fix, to use &amp;#39;*data&amp;#39; everywhere &amp;#39;net-&gt;sctp.sctp_hmac_alg&amp;#39; is<br /> used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: sysctl: blackhole timeout: avoid using current-&gt;nsproxy<br /> <br /> As mentioned in the previous commit, using the &amp;#39;net&amp;#39; structure via<br /> &amp;#39;current&amp;#39; is not recommended for different reasons:<br /> <br /> - Inconsistency: getting info from the reader&amp;#39;s/writer&amp;#39;s netns vs only<br /> from the opener&amp;#39;s netns.<br /> <br /> - current-&gt;nsproxy can be NULL in some cases, resulting in an &amp;#39;Oops&amp;#39;<br /> (null-ptr-deref), e.g. when the current task is exiting, as spotted by<br /> syzbot [1] using acct(2).<br /> <br /> The &amp;#39;pernet&amp;#39; structure can be obtained from the table-&gt;data using<br /> container_of().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: sysctl: sched: avoid using current-&gt;nsproxy<br /> <br /> Using the &amp;#39;net&amp;#39; structure via &amp;#39;current&amp;#39; is not recommended for different<br /> reasons.<br /> <br /> First, if the goal is to use it to read or write per-netns data, this is<br /> inconsistent with how the "generic" sysctl entries are doing: directly<br /> by only using pointers set to the table entry, e.g. table-&gt;data. Linked<br /> to that, the per-netns data should always be obtained from the table<br /> linked to the netns it had been created for, which may not coincide with<br /> the reader&amp;#39;s or writer&amp;#39;s netns.<br /> <br /> Another reason is that access to current-&gt;nsproxy-&gt;netns can oops if<br /> attempted when current-&gt;nsproxy had been dropped when the current task<br /> is exiting. This is what syzbot found, when using acct(2):<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125<br /> Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00<br /> RSP: 0018:ffffc900034774e8 EFLAGS: 00010206<br /> <br /> RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620<br /> RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028<br /> RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040<br /> R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000<br /> R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601<br /> __kernel_write_iter+0x318/0xa80 fs/read_write.c:612<br /> __kernel_write+0xf6/0x140 fs/read_write.c:632<br /> do_acct_process+0xcb0/0x14a0 kernel/acct.c:539<br /> acct_pin_kill+0x2d/0x100 kernel/acct.c:192<br /> pin_kill+0x194/0x7c0 fs/fs_pin.c:44<br /> mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81<br /> cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366<br /> task_work_run+0x14e/0x250 kernel/task_work.c:239<br /> exit_task_work include/linux/task_work.h:43 [inline]<br /> do_exit+0xad8/0x2d70 kernel/exit.c:938<br /> do_group_exit+0xd3/0x2a0 kernel/exit.c:1087<br /> get_signal+0x2576/0x2610 kernel/signal.c:3017<br /> arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop kernel/entry/common.c:111 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218<br /> do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fee3cb87a6a<br /> Code: Unable to access opcode bytes at 0x7fee3cb87a40.<br /> RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037<br /> RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a<br /> RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003<br /> RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7<br /> R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500<br /> R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125<br /> Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix kernel async DIO<br /> <br /> Netfslib needs to be able to handle kernel-initiated asynchronous DIO that<br /> is supplied with a bio_vec[] array. Currently, because of the async flag,<br /> this gets passed to netfs_extract_user_iter() which throws a warning and<br /> fails because it only handles IOVEC and UBUF iterators. This can be<br /> triggered through a combination of cifs and a loopback blockdev with<br /> something like:<br /> <br /> mount //my/cifs/share /foo<br /> dd if=/dev/zero of=/foo/m0 bs=4K count=1K<br /> losetup --sector-size 4096 --direct-io=on /dev/loop2046 /foo/m0<br /> echo hello &gt;/dev/loop2046<br /> <br /> This causes the following to appear in syslog:<br /> <br /> WARNING: CPU: 2 PID: 109 at fs/netfs/iterator.c:50 netfs_extract_user_iter+0x170/0x250 [netfs]<br /> <br /> and the write to fail.<br /> <br /> Fix this by removing the check in netfs_unbuffered_write_iter_locked() that<br /> causes async kernel DIO writes to be handled as userspace writes. Note<br /> that this change relies on the kernel caller maintaining the existence of<br /> the bio_vec array (or kvec[] or folio_queue) until the op is complete.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix tlb invalidation when wedging<br /> <br /> If GuC fails to load, the driver wedges, but in the process it tries to<br /> do stuff that may not be initialized yet. This moves the<br /> xe_gt_tlb_invalidation_init() to be done earlier: as its own doc says,<br /> it&amp;#39;s a software-only initialization and should had been named with the<br /> _early() suffix.<br /> <br /> Move it to be called by xe_gt_init_early(), so the locks and seqno are<br /> initialized, avoiding a NULL ptr deref when wedging:<br /> <br /> xe 0000:03:00.0: [drm] *ERROR* GT0: load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01<br /> xe 0000:03:00.0: [drm] *ERROR* GT0: firmware signature verification failed<br /> xe 0000:03:00.0: [drm] *ERROR* CRITICAL: Xe has declared device 0000:03:00.0 as wedged.<br /> ...<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 9 UID: 0 PID: 3908 Comm: modprobe Tainted: G U W 6.13.0-rc4-xe+ #3<br /> Tainted: [U]=USER, [W]=WARN<br /> Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DDR5 UDIMM CRB, BIOS ADLSFWI1.R00.3275.A00.2207010640 07/01/2022<br /> RIP: 0010:xe_gt_tlb_invalidation_reset+0x75/0x110 [xe]<br /> <br /> This can be easily triggered by poking the GuC binary to force a<br /> signature failure. There will still be an extra message,<br /> <br /> xe 0000:03:00.0: [drm] *ERROR* GT0: GuC mmio request 0x4100: no reply 0x4100<br /> <br /> but that&amp;#39;s better than a NULL ptr deref.<br /> <br /> (cherry picked from commit 5001ef3af8f2c972d6fd9c5221a8457556f8bea6)