Vulnerabilities

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix possible store tearing in neigh_periodic_work()<br /> <br /> While looking at a related syzbot report involving neigh_periodic_work(),<br /> I found that I forgot to add an annotation when deleting an<br /> RCU protected item from a list.<br /> <br /> Readers use rcu_deference(*np), we need to use either<br /> rcu_assign_pointer() or WRITE_ONCE() on writer side<br /> to prevent store tearing.<br /> <br /> I use rcu_assign_pointer() to have lockdep support,<br /> this was the choice made in neigh_flush_dev().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets<br /> <br /> With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages<br /> sent from one TCP socket (s1) to actually egress from another TCP<br /> socket (s2):<br /> <br /> tcp_bpf_sendmsg(s1) // = sk_prot-&gt;sendmsg<br /> tcp_bpf_send_verdict(s1) // __SK_REDIRECT case<br /> tcp_bpf_sendmsg_redir(s2)<br /> tcp_bpf_push_locked(s2)<br /> tcp_bpf_push(s2)<br /> tcp_rate_check_app_limited(s2) // expects tcp_sock<br /> tcp_sendmsg_locked(s2) // ditto<br /> <br /> There is a hard-coded assumption in the call-chain, that the egress<br /> socket (s2) is a TCP socket.<br /> <br /> However in commit 122e6c79efe1 ("sock_map: Update sock type checks for<br /> UDP") we have enabled redirects to non-TCP sockets. This was done for the<br /> sake of BPF sk_skb programs. There was no indention to support sk_msg<br /> send-to-egress use case.<br /> <br /> As a result, attempts to send-to-egress through a non-TCP socket lead to a<br /> crash due to invalid downcast from sock to tcp_sock:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000002f<br /> ...<br /> Call Trace:<br /> <br /> ? show_regs+0x60/0x70<br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x80/0x160<br /> ? do_user_addr_fault+0x2d7/0x800<br /> ? rcu_is_watching+0x11/0x50<br /> ? exc_page_fault+0x70/0x1c0<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? tcp_tso_segs+0x14/0xa0<br /> tcp_write_xmit+0x67/0xce0<br /> __tcp_push_pending_frames+0x32/0xf0<br /> tcp_push+0x107/0x140<br /> tcp_sendmsg_locked+0x99f/0xbb0<br /> tcp_bpf_push+0x19d/0x3a0<br /> tcp_bpf_sendmsg_redir+0x55/0xd0<br /> tcp_bpf_send_verdict+0x407/0x550<br /> tcp_bpf_sendmsg+0x1a1/0x390<br /> inet_sendmsg+0x6a/0x70<br /> sock_sendmsg+0x9d/0xc0<br /> ? sockfd_lookup_light+0x12/0x80<br /> __sys_sendto+0x10e/0x160<br /> ? syscall_enter_from_user_mode+0x20/0x60<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> ? lockdep_hardirqs_on+0x82/0x110<br /> __x64_sys_sendto+0x1f/0x30<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg<br /> program to prevent the crash. When attempted, user will receive an EACCES<br /> error from send/sendto/sendmsg() syscall.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nfc: llcp: Add lock when modifying device list<br /> <br /> The device list needs its associated lock held when modifying it, or the<br /> list could become corrupted, as syzbot discovered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet<br /> <br /> Only skip the code path trying to access the rfc1042 headers when the<br /> buffer is too small, so the driver can still process packets without<br /> rfc1042 headers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix memory leak of LZMA global compressed deduplication<br /> <br /> When stressing microLZMA EROFS images with the new global compressed<br /> deduplication feature enabled (`-Ededupe`), I found some short-lived<br /> temporary pages weren&amp;#39;t properly released, which could slowly cause<br /> unexpected OOMs hours later.<br /> <br /> Let&amp;#39;s fix it now (LZ4 and DEFLATE don&amp;#39;t have this issue.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()<br /> <br /> Including the transhdrlen in length is a problem when the packet is<br /> partially filled (e.g. something like send(MSG_MORE) happened previously)<br /> when appending to an IPv4 or IPv6 packet as we don&amp;#39;t want to repeat the<br /> transport header or account for it twice. This can happen under some<br /> circumstances, such as splicing into an L2TP socket.<br /> <br /> The symptom observed is a warning in __ip6_append_data():<br /> <br /> WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800<br /> <br /> that occurs when MSG_SPLICE_PAGES is used to append more data to an already<br /> partially occupied skbuff. The warning occurs when &amp;#39;copy&amp;#39; is larger than<br /> the amount of data in the message iterator. This is because the requested<br /> length includes the transport header length when it shouldn&amp;#39;t. This can be<br /> triggered by, for example:<br /> <br /> sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);<br /> bind(sfd, ...); // ::1<br /> connect(sfd, ...); // ::1 port 7<br /> send(sfd, buffer, 4100, MSG_MORE);<br /> sendfile(sfd, dfd, NULL, 1024);<br /> <br /> Fix this by only adding transhdrlen into the length if the write queue is<br /> empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.<br /> <br /> l2tp_ip_sendmsg() looks like it won&amp;#39;t suffer from this problem as it builds<br /> the UDP packet itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg<br /> <br /> syzbot reported the following uninit-value access issue:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]<br /> BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x21c/0x280 lib/dump_stack.c:118<br /> kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121<br /> __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]<br /> smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737<br /> usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374<br /> really_probe+0xf20/0x20b0 drivers/base/dd.c:529<br /> driver_probe_device+0x293/0x390 drivers/base/dd.c:701<br /> __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807<br /> bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431<br /> __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:920<br /> bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491<br /> device_add+0x3b0e/0x40d0 drivers/base/core.c:2680<br /> usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032<br /> usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241<br /> usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272<br /> really_probe+0xf20/0x20b0 drivers/base/dd.c:529<br /> driver_probe_device+0x293/0x390 drivers/base/dd.c:701<br /> __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807<br /> bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431<br /> __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:920<br /> bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491<br /> device_add+0x3b0e/0x40d0 drivers/base/core.c:2680<br /> usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554<br /> hub_port_connect drivers/usb/core/hub.c:5208 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]<br /> port_event drivers/usb/core/hub.c:5494 [inline]<br /> hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576<br /> process_one_work+0x1688/0x2140 kernel/workqueue.c:2269<br /> worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415<br /> kthread+0x551/0x590 kernel/kthread.c:292<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293<br /> <br /> Local variable ----buf.i87@smsc75xx_bind created at:<br /> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]<br /> smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]<br /> smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> <br /> This issue is caused because usbnet_read_cmd() reads less bytes than requested<br /> (zero byte in the reproducer). In this case, &amp;#39;buf&amp;#39; is not properly filled.<br /> <br /> This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads<br /> less bytes than requested.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: sony: Fix a potential memory leak in sony_probe()<br /> <br /> If an error occurs after a successful usb_alloc_urb() call, usb_free_urb()<br /> should be called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: Fix a memory corruption issue<br /> <br /> A few lines above, space is kzalloc()&amp;#39;ed for:<br /> sizeof(struct iwl_nvm_data) +<br /> sizeof(struct ieee80211_channel) +<br /> sizeof(struct ieee80211_rate)<br /> <br /> &amp;#39;mvm-&gt;nvm_data&amp;#39; is a &amp;#39;struct iwl_nvm_data&amp;#39;, so it is fine.<br /> <br /> At the end of this structure, there is the &amp;#39;channels&amp;#39; flex array.<br /> Each element is of type &amp;#39;struct ieee80211_channel&amp;#39;.<br /> So only 1 element is allocated in this array.<br /> <br /> When doing:<br /> mvm-&gt;nvm_data-&gt;bands[0].channels = mvm-&gt;nvm_data-&gt;channels;<br /> We point at the first element of the &amp;#39;channels&amp;#39; flex array.<br /> So this is fine.<br /> <br /> However, when doing:<br /> mvm-&gt;nvm_data-&gt;bands[0].bitrates =<br /> (void *)((u8 *)mvm-&gt;nvm_data-&gt;channels + 1);<br /> because of the "(u8 *)" cast, we add only 1 to the address of the beginning<br /> of the flex array.<br /> <br /> It is likely that we want point at the &amp;#39;struct ieee80211_rate&amp;#39; allocated<br /> just after.<br /> <br /> Remove the spurious casting so that the pointer arithmetic works as<br /> expected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix TX CQE error handling<br /> <br /> For an unknown TX CQE error type (probably from a newer hardware),<br /> still free the SKB, update the queue tail, etc., otherwise the<br /> accounting will be wrong.<br /> <br /> Also, TX errors can be triggered by injecting corrupted packets, so<br /> replace the WARN_ONCE to ratelimited error logging.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Avoid memory allocation in iommu_suspend()<br /> <br /> The iommu_suspend() syscore suspend callback is invoked with IRQ disabled.<br /> Allocating memory with the GFP_KERNEL flag may re-enable IRQs during<br /> the suspend callback, which can cause intermittent suspend/hibernation<br /> problems with the following kernel traces:<br /> <br /> Calling iommu_suspend+0x0/0x1d0<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0<br /> ...<br /> CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1<br /> RIP: 0010:ktime_get+0x9b/0xb0<br /> ...<br /> Call Trace:<br /> <br /> tick_sched_timer+0x22/0x90<br /> ? __pfx_tick_sched_timer+0x10/0x10<br /> __hrtimer_run_queues+0x111/0x2b0<br /> hrtimer_interrupt+0xfa/0x230<br /> __sysvec_apic_timer_interrupt+0x63/0x140<br /> sysvec_apic_timer_interrupt+0x7b/0xa0<br /> <br /> <br /> asm_sysvec_apic_timer_interrupt+0x1f/0x30<br /> ...<br /> ------------[ cut here ]------------<br /> Interrupts enabled after iommu_suspend+0x0/0x1d0<br /> WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270<br /> CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1<br /> RIP: 0010:syscore_suspend+0x147/0x270<br /> ...<br /> Call Trace:<br /> <br /> hibernation_snapshot+0x25b/0x670<br /> hibernate+0xcd/0x390<br /> state_store+0xcf/0xe0<br /> kobj_attr_store+0x13/0x30<br /> sysfs_kf_write+0x3f/0x50<br /> kernfs_fop_write_iter+0x128/0x200<br /> vfs_write+0x1fd/0x3c0<br /> ksys_write+0x6f/0xf0<br /> __x64_sys_write+0x1d/0x30<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Given that only 4 words memory is needed, avoid the memory allocation in<br /> iommu_suspend().