Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: drv: netdevsim: don&amp;#39;t napi_complete() from netpoll<br /> <br /> netdevsim supports netpoll. Make sure we don&amp;#39;t call napi_complete()<br /> from it, since it may not be scheduled. Breno reports hitting a<br /> warning in napi_complete_done():<br /> <br /> WARNING: CPU: 14 PID: 104 at net/core/dev.c:6592 napi_complete_done+0x2cc/0x560<br /> __napi_poll+0x2d8/0x3a0<br /> handle_softirqs+0x1fe/0x710<br /> <br /> This is presumably after netpoll stole the SCHED bit prematurely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: prevent a NULL deref in rtnl_create_link()<br /> <br /> At the time rtnl_create_link() is running, dev-&gt;netdev_ops is NULL,<br /> we must not use netdev_lock_ops() or risk a NULL deref if<br /> CONFIG_NET_SHAPER is defined.<br /> <br /> Use netif_set_group() instead of dev_set_group().<br /> <br /> RIP: 0010:netdev_need_ops_lock include/net/netdev_lock.h:33 [inline]<br /> RIP: 0010:netdev_lock_ops include/net/netdev_lock.h:41 [inline]<br /> RIP: 0010:dev_set_group+0xc0/0x230 net/core/dev_api.c:82<br /> Call Trace:<br /> <br /> rtnl_create_link+0x748/0xd10 net/core/rtnetlink.c:3674<br /> rtnl_newlink_create+0x25c/0xb00 net/core/rtnetlink.c:3813<br /> __rtnl_newlink net/core/rtnetlink.c:3940 [inline]<br /> rtnl_newlink+0x16d6/0x1c70 net/core/rtnetlink.c:4055<br /> rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6944<br /> netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2534<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]<br /> netlink_unicast+0x75b/0x8d0 net/netlink/af_netlink.c:1339<br /> netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1883<br /> sock_sendmsg_nosec net/socket.c:712 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: b53: do not enable EEE on bcm63xx<br /> <br /> BCM63xx internal switches do not support EEE, but provide multiple RGMII<br /> ports where external PHYs may be connected. If one of these PHYs are EEE<br /> capable, we may try to enable EEE for the MACs, which then hangs the<br /> system on access of the (non-existent) EEE registers.<br /> <br /> Fix this by checking if the switch actually supports EEE before<br /> attempting to configure it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tipc: fix refcount warning in tipc_aead_encrypt<br /> <br /> syzbot reported a refcount warning [1] caused by calling get_net() on<br /> a network namespace that is being destroyed (refcount=0). This happens<br /> when a TIPC discovery timer fires during network namespace cleanup.<br /> <br /> The recently added get_net() call in commit e279024617134 ("net/tipc:<br /> fix slab-use-after-free Read in tipc_aead_encrypt_done") attempts to<br /> hold a reference to the network namespace. However, if the namespace<br /> is already being destroyed, its refcount might be zero, leading to the<br /> use-after-free warning.<br /> <br /> Replace get_net() with maybe_get_net(), which safely checks if the<br /> refcount is non-zero before incrementing it. If the namespace is being<br /> destroyed, return -ENODEV early, after releasing the bearer reference.<br /> <br /> [1]: https://lore.kernel.org/all/68342b55.a70a0220.253bc2.0091.GAE@google.com/T/#m12019cf9ae77e1954f666914640efa36d52704a2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: fix potential null pointer deref in fpga_mgr_test_img_load_sgt()<br /> <br /> fpga_mgr_test_img_load_sgt() allocates memory for sgt using<br /> kunit_kzalloc() however it does not check if the allocation failed.<br /> It then passes sgt to sg_alloc_table(), which passes it to<br /> __sg_alloc_table(). This function calls memset() on sgt in an attempt to<br /> zero it out. If the allocation fails then sgt will be NULL and the<br /> memset will trigger a NULL pointer dereference.<br /> <br /> Fix this by checking the allocation with KUNIT_ASSERT_NOT_ERR_OR_NULL().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bug<br /> <br /> The qmp_usb_iomap() helper function currently returns the raw result of<br /> devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return<br /> a NULL pointer and the caller only checks error pointers with IS_ERR(),<br /> NULL could bypass the check and lead to an invalid dereference.<br /> <br /> Fix the issue by checking if devm_ioremap() returns NULL. When it does,<br /> qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM),<br /> ensuring safe and consistent error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/dax: Fix "don&amp;#39;t skip locked entries when scanning entries"<br /> <br /> Commit 6be3e21d25ca ("fs/dax: don&amp;#39;t skip locked entries when scanning<br /> entries") introduced a new function, wait_entry_unlocked_exclusive(),<br /> which waits for the current entry to become unlocked without advancing<br /> the XArray iterator state.<br /> <br /> Waiting for the entry to become unlocked requires dropping the XArray<br /> lock. This requires calling xas_pause() prior to dropping the lock<br /> which leaves the xas in a suitable state for the next iteration. However<br /> this has the side-effect of advancing the xas state to the next index.<br /> Normally this isn&amp;#39;t an issue because xas_for_each() contains code to<br /> detect this state and thus avoid advancing the index a second time on<br /> the next loop iteration.<br /> <br /> However both callers of and wait_entry_unlocked_exclusive() itself<br /> subsequently use the xas state to reload the entry. As xas_pause()<br /> updated the state to the next index this will cause the current entry<br /> which is being waited on to be skipped. This caused the following<br /> warning to fire intermittently when running xftest generic/068 on an XFS<br /> filesystem with FS DAX enabled:<br /> <br /> [ 35.067397] ------------[ cut here ]------------<br /> [ 35.068229] WARNING: CPU: 21 PID: 1640 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xd8/0x1e0<br /> [ 35.069717] Modules linked in: nd_pmem dax_pmem nd_btt nd_e820 libnvdimm<br /> [ 35.071006] CPU: 21 UID: 0 PID: 1640 Comm: fstest Not tainted 6.15.0-rc7+ #77 PREEMPT(voluntary)<br /> [ 35.072613] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/204<br /> [ 35.074845] RIP: 0010:truncate_folio_batch_exceptionals+0xd8/0x1e0<br /> [ 35.075962] Code: a1 00 00 00 f6 47 0d 20 0f 84 97 00 00 00 4c 63 e8 41 39 c4 7f 0b eb 61 49 83 c5 01 45 39 ec 7e 58 42 f68<br /> [ 35.079522] RSP: 0018:ffffb04e426c7850 EFLAGS: 00010202<br /> [ 35.080359] RAX: 0000000000000000 RBX: ffff9d21e3481908 RCX: ffffb04e426c77f4<br /> [ 35.081477] RDX: ffffb04e426c79e8 RSI: ffffb04e426c79e0 RDI: ffff9d21e34816e8<br /> [ 35.082590] RBP: ffffb04e426c79e0 R08: 0000000000000001 R09: 0000000000000003<br /> [ 35.083733] R10: 0000000000000000 R11: 822b53c0f7a49868 R12: 000000000000001f<br /> [ 35.084850] R13: 0000000000000000 R14: ffffb04e426c78e8 R15: fffffffffffffffe<br /> [ 35.085953] FS: 00007f9134c87740(0000) GS:ffff9d22abba0000(0000) knlGS:0000000000000000<br /> [ 35.087346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 35.088244] CR2: 00007f9134c86000 CR3: 000000040afff000 CR4: 00000000000006f0<br /> [ 35.089354] Call Trace:<br /> [ 35.089749] <br /> [ 35.090168] truncate_inode_pages_range+0xfc/0x4d0<br /> [ 35.091078] truncate_pagecache+0x47/0x60<br /> [ 35.091735] xfs_setattr_size+0xc7/0x3e0<br /> [ 35.092648] xfs_vn_setattr+0x1ea/0x270<br /> [ 35.093437] notify_change+0x1f4/0x510<br /> [ 35.094219] ? do_truncate+0x97/0xe0<br /> [ 35.094879] do_truncate+0x97/0xe0<br /> [ 35.095640] path_openat+0xabd/0xca0<br /> [ 35.096278] do_filp_open+0xd7/0x190<br /> [ 35.096860] do_sys_openat2+0x8a/0xe0<br /> [ 35.097459] __x64_sys_openat+0x6d/0xa0<br /> [ 35.098076] do_syscall_64+0xbb/0x1d0<br /> [ 35.098647] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 35.099444] RIP: 0033:0x7f9134d81fc1<br /> [ 35.100033] Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d 2a 26 0e 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff5<br /> [ 35.102993] RSP: 002b:00007ffcd41e0d10 EFLAGS: 00000202 ORIG_RAX: 0000000000000101<br /> [ 35.104263] RAX: ffffffffffffffda RBX: 0000000000000242 RCX: 00007f9134d81fc1<br /> [ 35.105452] RDX: 0000000000000242 RSI: 00007ffcd41e1200 RDI: 00000000ffffff9c<br /> [ 35.106663] RBP: 00007ffcd41e1200 R08: 0000000000000000 R09: 0000000000000064<br /> [ 35.107923] R10: 00000000000001a4 R11: 0000000000000202 R12: 0000000000000066<br /> [ 35.109112] R13: 0000000000100000 R14: 0000000000100000 R15: 0000000000000400<br /> [ 35.110357] <br /> [ 35.110769] irq event stamp: 8415587<br /> [ 35.111486] hardirqs last enabled at (8415599): [] __up_console_se<br /> ---truncated---

A flaw was found in GnuTLS. A double-free vulnerability exists in GnuTLS due to incorrect ownership handling in the export logic of Subject Alternative Name (SAN) entries containing an otherName. If the type-id OID is invalid or malformed, GnuTLS will call asn1_delete_structure() on an ASN.1 node it does not own, leading to a double-free condition when the parent function or caller later attempts to free the same structure.<br /> <br /> This vulnerability can be triggered using only public GnuTLS APIs and may result in denial of service or memory corruption, depending on allocator behavior.

A heap-buffer-overread vulnerability was found in GnuTLS in how it handles the Certificate Transparency (CT) Signed Certificate Timestamp (SCT) extension during X.509 certificate parsing. This flaw allows a malicious user to create a certificate containing a malformed SCT extension (OID 1.3.6.1.4.1.11129.2.4.2) that contains sensitive data. This issue leads to the exposure of confidential information when GnuTLS verifies certificates from certain websites when the certificate (SCT) is not checked correctly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: jsm: fix NPE during jsm_uart_port_init<br /> <br /> No device was set which caused serial_base_ctrl_add to crash.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000050<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1 Debian 6.12.25-1<br /> RIP: 0010:serial_base_ctrl_add+0x96/0x120<br /> Call Trace:<br /> <br /> serial_core_register_port+0x1a0/0x580<br /> ? __setup_irq+0x39c/0x660<br /> ? __kmalloc_cache_noprof+0x111/0x310<br /> jsm_uart_port_init+0xe8/0x180 [jsm]<br /> jsm_probe_one+0x1f4/0x410 [jsm]<br /> local_pci_probe+0x42/0x90<br /> pci_device_probe+0x22f/0x270<br /> really_probe+0xdb/0x340<br /> ? pm_runtime_barrier+0x54/0x90<br /> ? __pfx___driver_attach+0x10/0x10<br /> __driver_probe_device+0x78/0x110<br /> driver_probe_device+0x1f/0xa0<br /> __driver_attach+0xba/0x1c0<br /> bus_for_each_dev+0x8c/0xe0<br /> bus_add_driver+0x112/0x1f0<br /> driver_register+0x72/0xd0<br /> jsm_init_module+0x36/0xff0 [jsm]<br /> ? __pfx_jsm_init_module+0x10/0x10 [jsm]<br /> do_one_initcall+0x58/0x310<br /> do_init_module+0x60/0x230<br /> <br /> Tested with Digi Neo PCIe 8 port card.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: mediatek: eint: Fix invalid pointer dereference for v1 platforms<br /> <br /> Commit 3ef9f710efcb ("pinctrl: mediatek: Add EINT support for multiple<br /> addresses") introduced an access to the &amp;#39;soc&amp;#39; field of struct<br /> mtk_pinctrl in mtk_eint_do_init() and for that an include of<br /> pinctrl-mtk-common-v2.h.<br /> <br /> However, pinctrl drivers relying on the v1 common driver include<br /> pinctrl-mtk-common.h instead, which provides another definition of<br /> struct mtk_pinctrl that does not contain an &amp;#39;soc&amp;#39; field.<br /> <br /> Since mtk_eint_do_init() can be called both by v1 and v2 drivers, it<br /> will now try to dereference an invalid pointer when called on v1<br /> platforms. This has been observed on Genio 350 EVK (MT8365), which<br /> crashes very early in boot (the kernel trace can only be seen with<br /> earlycon).<br /> <br /> In order to fix this, since &amp;#39;struct mtk_pinctrl&amp;#39; was only needed to get<br /> a &amp;#39;struct mtk_eint_pin&amp;#39;, make &amp;#39;struct mtk_eint_pin&amp;#39; a parameter<br /> of mtk_eint_do_init() so that callers need to supply it, removing<br /> mtk_eint_do_init()&amp;#39;s dependency on any particular &amp;#39;struct mtk_pinctrl&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Do not trigger WARN_ON() due to a commit_overrun<br /> <br /> When reading a memory mapped buffer the reader page is just swapped out<br /> with the last page written in the write buffer. If the reader page is the<br /> same as the commit buffer (the buffer that is currently being written to)<br /> it was assumed that it should never have missed events. If it does, it<br /> triggers a WARN_ON_ONCE().<br /> <br /> But there just happens to be one scenario where this can legitimately<br /> happen. That is on a commit_overrun. A commit overrun is when an interrupt<br /> preempts an event being written to the buffer and then the interrupt adds<br /> so many new events that it fills and wraps the buffer back to the commit.<br /> Any new events would then be dropped and be reported as "missed_events".<br /> <br /> In this case, the next page to read is the commit buffer and after the<br /> swap of the reader page, the reader page will be the commit buffer, but<br /> this time there will be missed events and this triggers the following<br /> warning:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 1127 at kernel/trace/ring_buffer.c:7357 ring_buffer_map_get_reader+0x49a/0x780<br /> Modules linked in: kvm_intel kvm irqbypass<br /> CPU: 2 UID: 0 PID: 1127 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00004-g478bc2824b45-dirty #564 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:ring_buffer_map_get_reader+0x49a/0x780<br /> Code: 00 00 00 48 89 fe 48 c1 ee 03 80 3c 2e 00 0f 85 ec 01 00 00 4d 3b a6 a8 00 00 00 0f 85 8a fd ff ff 48 85 c0 0f 84 55 fe ff ff 0b e9 4e fe ff ff be 08 00 00 00 4c 89 54 24 58 48 89 54 24 50<br /> RSP: 0018:ffff888121787dc0 EFLAGS: 00010002<br /> RAX: 00000000000006a2 RBX: ffff888100062800 RCX: ffffffff8190cb49<br /> RDX: ffff888126934c00 RSI: 1ffff11020200a15 RDI: ffff8881010050a8<br /> RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffed1024d26982<br /> R10: ffff888126934c17 R11: ffff8881010050a8 R12: ffff888126934c00<br /> R13: ffff8881010050b8 R14: ffff888101005000 R15: ffff888126930008<br /> FS: 00007f95c8cd7540(0000) GS:ffff8882b576e000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f95c8de4dc0 CR3: 0000000128452002 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __pfx_ring_buffer_map_get_reader+0x10/0x10<br /> tracing_buffers_ioctl+0x283/0x370<br /> __x64_sys_ioctl+0x134/0x190<br /> do_syscall_64+0x79/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f95c8de48db<br /> Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 c2 3d 00 f0 ff ff 77 1c 48 8b 44 24 18 64 48 2b 04 25 28 00 00<br /> RSP: 002b:00007ffe037ba110 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffe037bb2b0 RCX: 00007f95c8de48db<br /> RDX: 0000000000000000 RSI: 0000000000005220 RDI: 0000000000000006<br /> RBP: 00007ffe037ba180 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffe037bb6f8 R14: 00007f95c9065000 R15: 00005575c7492c90<br /> <br /> irq event stamp: 5080<br /> hardirqs last enabled at (5079): [] _raw_spin_unlock_irqrestore+0x50/0x70<br /> hardirqs last disabled at (5080): [] _raw_spin_lock_irqsave+0x63/0x70<br /> softirqs last enabled at (4182): [] handle_softirqs+0x552/0x710<br /> softirqs last disabled at (4159): [] __irq_exit_rcu+0x107/0x210<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The above was triggered by running on a kernel with both lockdep and KASAN<br /> as well as kmemleak enabled and executing the following command:<br /> <br /> # perf record -o perf-test.dat -a -- trace-cmd record --nosplice -e all -p function hackbench 50<br /> <br /> With perf interjecting a lot of interrupts and trace-cmd enabling all<br /> events as well as function tracing, with lockdep, KASAN and kmemleak<br /> enabled, it could cause an interrupt preempting an event being written to<br /> add enough event<br /> ---truncated---