Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: base: Free devm resources when unregistering a device<br /> <br /> In the current code, devres_release_all() only gets called if the device<br /> has a bus and has been probed.<br /> <br /> This leads to issues when using bus-less or driver-less devices where<br /> the device might never get freed if a managed resource holds a reference<br /> to the device. This is happening in the DRM framework for example.<br /> <br /> We should thus call devres_release_all() in the device_del() function to<br /> make sure that the device-managed actions are properly executed when the<br /> device is unregistered, even if it has neither a bus nor a driver.<br /> <br /> This is effectively the same change than commit 2f8d16a996da ("devres:<br /> release resources on device_del()") that got reverted by commit<br /> a525a3ddeaca ("driver core: free devres in device_release") over<br /> memory leaks concerns.<br /> <br /> This patch effectively combines the two commits mentioned above to<br /> release the resources both on device_del() and device_release() and get<br /> the best of both worlds.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: mcs: Fix NULL pointer dereferences<br /> <br /> When system is rebooted after creating macsec interface<br /> below NULL pointer dereference crashes occurred. This<br /> patch fixes those crashes by using correct order of teardown<br /> <br /> [ 3324.406942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 3324.415726] Mem abort info:<br /> [ 3324.418510] ESR = 0x96000006<br /> [ 3324.421557] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 3324.426865] SET = 0, FnV = 0<br /> [ 3324.429913] EA = 0, S1PTW = 0<br /> [ 3324.433047] Data abort info:<br /> [ 3324.435921] ISV = 0, ISS = 0x00000006<br /> [ 3324.439748] CM = 0, WnR = 0<br /> ....<br /> [ 3324.575915] Call trace:<br /> [ 3324.578353] cn10k_mdo_del_secy+0x24/0x180<br /> [ 3324.582440] macsec_common_dellink+0xec/0x120<br /> [ 3324.586788] macsec_notify+0x17c/0x1c0<br /> [ 3324.590529] raw_notifier_call_chain+0x50/0x70<br /> [ 3324.594965] call_netdevice_notifiers_info+0x34/0x7c<br /> [ 3324.599921] rollback_registered_many+0x354/0x5bc<br /> [ 3324.604616] unregister_netdevice_queue+0x88/0x10c<br /> [ 3324.609399] unregister_netdev+0x20/0x30<br /> [ 3324.613313] otx2_remove+0x8c/0x310<br /> [ 3324.616794] pci_device_shutdown+0x30/0x70<br /> [ 3324.620882] device_shutdown+0x11c/0x204<br /> <br /> [ 966.664930] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 966.673712] Mem abort info:<br /> [ 966.676497] ESR = 0x96000006<br /> [ 966.679543] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 966.684848] SET = 0, FnV = 0<br /> [ 966.687895] EA = 0, S1PTW = 0<br /> [ 966.691028] Data abort info:<br /> [ 966.693900] ISV = 0, ISS = 0x00000006<br /> [ 966.697729] CM = 0, WnR = 0<br /> [ 966.833467] Call trace:<br /> [ 966.835904] cn10k_mdo_stop+0x20/0xa0<br /> [ 966.839557] macsec_dev_stop+0xe8/0x11c<br /> [ 966.843384] __dev_close_many+0xbc/0x140<br /> [ 966.847298] dev_close_many+0x84/0x120<br /> [ 966.851039] rollback_registered_many+0x114/0x5bc<br /> [ 966.855735] unregister_netdevice_many.part.0+0x14/0xa0<br /> [ 966.860952] unregister_netdevice_many+0x18/0x24<br /> [ 966.865560] macsec_notify+0x1ac/0x1c0<br /> [ 966.869303] raw_notifier_call_chain+0x50/0x70<br /> [ 966.873738] call_netdevice_notifiers_info+0x34/0x7c<br /> [ 966.878694] rollback_registered_many+0x354/0x5bc<br /> [ 966.883390] unregister_netdevice_queue+0x88/0x10c<br /> [ 966.888173] unregister_netdev+0x20/0x30<br /> [ 966.892090] otx2_remove+0x8c/0x310<br /> [ 966.895571] pci_device_shutdown+0x30/0x70<br /> [ 966.899660] device_shutdown+0x11c/0x204<br /> [ 966.903574] __do_sys_reboot+0x208/0x290<br /> [ 966.907487] __arm64_sys_reboot+0x20/0x30<br /> [ 966.911489] el0_svc_handler+0x80/0x1c0<br /> [ 966.915316] el0_svc+0x8/0x180<br /> [ 966.918362] Code: f9400000 f9400a64 91220014 f94b3403 (f9400060)<br /> [ 966.924448] ---[ end trace 341778e799c3d8d7 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: Range check CHDBOFF and ERDBOFF<br /> <br /> If the value read from the CHDBOFF and ERDBOFF registers is outside the<br /> range of the MHI register space then an invalid address might be computed<br /> which later causes a kernel panic. Range check the read value to prevent<br /> a crash due to bad data from the device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: fix mid leak during reconnection after timeout threshold<br /> <br /> When the number of responses with status of STATUS_IO_TIMEOUT<br /> exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect<br /> the connection. But we do not return the mid, or the credits<br /> returned for the mid, or reduce the number of in-flight requests.<br /> <br /> This bug could result in the server-&gt;in_flight count to go bad,<br /> and also cause a leak in the mids.<br /> <br /> This change moves the check to a few lines below where the<br /> response is decrypted, even of the response is read from the<br /> transform header. This way, the code for returning the mids<br /> can be reused.<br /> <br /> Also, the cifs_reconnect was reconnecting just the transport<br /> connection before. In case of multi-channel, this may not be<br /> what we want to do after several timeouts. Changed that to<br /> reconnect the session and the tree too.<br /> <br /> Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name<br /> MAX_STATUS_IO_TIMEOUT.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tunnels: fix kasan splat when generating ipv4 pmtu error<br /> <br /> If we try to emit an icmp error in response to a nonliner skb, we get<br /> <br /> BUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220<br /> Read of size 4 at addr ffff88811c50db00 by task iperf3/1691<br /> CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309<br /> [..]<br /> kasan_report+0x105/0x140<br /> ip_compute_csum+0x134/0x220<br /> iptunnel_pmtud_build_icmp+0x554/0x1020<br /> skb_tunnel_check_pmtu+0x513/0xb80<br /> vxlan_xmit_one+0x139e/0x2ef0<br /> vxlan_xmit+0x1867/0x2760<br /> dev_hard_start_xmit+0x1ee/0x4f0<br /> br_dev_queue_push_xmit+0x4d1/0x660<br /> [..]<br /> <br /> ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.<br /> After this change, splat is gone and iperf3 is no longer stuck.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390<br /> <br /> Fix af_alg_alloc_areq() to initialise areq-&gt;first_rsgl.sgl.sgt.sgl to point<br /> to the scatterlist array in areq-&gt;first_rsgl.sgl.sgl.<br /> <br /> Without this, the gcm-aes-s390 driver will oops when it tries to do<br /> gcm_walk_start() on req-&gt;dst because req-&gt;dst is set to the value of<br /> areq-&gt;first_rsgl.sgl.sgl by _aead_recvmsg() calling<br /> aead_request_set_crypt().<br /> <br /> The problem comes if an empty ciphertext is passed: the loop in<br /> af_alg_get_rsgl() just passes straight out and doesn&amp;#39;t set areq-&gt;first_rsgl<br /> up.<br /> <br /> This isn&amp;#39;t a problem on x86_64 using gcmaes_crypt_by_sg() because, as far<br /> as I can tell, that ignores req-&gt;dst and only uses req-&gt;src[*].<br /> <br /> [*] Is this a bug in aesni-intel_glue.c?<br /> <br /> The s390x oops looks something like:<br /> <br /> Unable to handle kernel pointer dereference in virtual kernel address space<br /> Failing address: 0000000a00000000 TEID: 0000000a00000803<br /> Fault in home space mode while using kernel ASCE.<br /> AS:00000000a43a0007 R3:0000000000000024<br /> Oops: 003b ilc:2 [#1] SMP<br /> ...<br /> Call Trace:<br /> [] gcm_walk_start+0x16/0x28 [aes_s390]<br /> [] crypto_aead_decrypt+0x9a/0xb8<br /> [] aead_recvmsg+0x478/0x698<br /> [] sock_recvmsg+0x70/0xb0<br /> [] sock_read_iter+0x76/0xa0<br /> [] vfs_read+0x26e/0x2a8<br /> [] ksys_read+0xbc/0x100<br /> [] __do_syscall+0x1d0/0x1f8<br /> [] system_call+0x70/0x98<br /> Last Breaking-Event-Address:<br /> [] gcm_aes_crypt+0x104/0xa68 [aes_s390]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix memory leak in WMI firmware stats<br /> <br /> Memory allocated for firmware pdev, vdev and beacon statistics<br /> are not released during rmmod.<br /> <br /> Fix it by calling ath11k_fw_stats_free() function before hardware<br /> unregister.<br /> <br /> While at it, avoid calling ath11k_fw_stats_free() while processing<br /> the firmware stats received in the WMI event because the local list<br /> is getting spliced and reinitialised and hence there are no elements<br /> in the list after splicing.<br /> <br /> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: do not assume skb mac_header is set<br /> <br /> Drivers must not assume in their ndo_start_xmit() that<br /> skbs have their mac_header set. skb-&gt;data is all what is needed.<br /> <br /> bonding seems to be one of the last offender as caught by syzbot:<br /> <br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470<br /> Modules linked in:<br /> CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023<br /> RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]<br /> RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]<br /> RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]<br /> RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]<br /> RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]<br /> RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]<br /> RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470<br /> Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe<br /> RSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283<br /> RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000<br /> RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6<br /> RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584<br /> R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e<br /> R13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76<br /> FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> [] netdev_start_xmit include/linux/netdevice.h:4925 [inline]<br /> [] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380<br /> [] dev_direct_xmit include/linux/netdevice.h:3043 [inline]<br /> [] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284<br /> [] packet_snd net/packet/af_packet.c:3112 [inline]<br /> [] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143<br /> [] sock_sendmsg_nosec net/socket.c:716 [inline]<br /> [] sock_sendmsg net/socket.c:736 [inline]<br /> [] __sys_sendto+0x472/0x5f0 net/socket.c:2139<br /> [] __do_sys_sendto net/socket.c:2151 [inline]<br /> [] __se_sys_sendto net/socket.c:2147 [inline]<br /> [] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Avoid fcport pointer dereference<br /> <br /> Klocwork reported warning of NULL pointer may be dereferenced. The routine<br /> exits when sa_ctl is NULL and fcport is allocated after the exit call thus<br /> causing NULL fcport pointer to dereference at the time of exit.<br /> <br /> To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t trust firmware n_channels<br /> <br /> If the firmware sends us a corrupted MCC response with<br /> n_channels much larger than the command response can be,<br /> we might copy far too much (uninitialized) memory and<br /> even crash if the n_channels is large enough to make it<br /> run out of the one page allocated for the FW response.<br /> <br /> Fix that by checking the lengths. Doing a

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop<br /> <br /> With this refcnt added in sctp_stream_priorities, we don&amp;#39;t need to<br /> traverse all streams to check if the prio is used by other streams<br /> when freeing one stream&amp;#39;s prio in sctp_sched_prio_free_sid(). This<br /> can avoid a nested loop (up to 65535 * 65535), which may cause a<br /> stuck as Ying reported:<br /> <br /> watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]<br /> Call Trace:<br /> <br /> sctp_sched_prio_free_sid+0xab/0x100 [sctp]<br /> sctp_stream_free_ext+0x64/0xa0 [sctp]<br /> sctp_stream_free+0x31/0x50 [sctp]<br /> sctp_association_free+0xa5/0x200 [sctp]<br /> <br /> Note that it doesn&amp;#39;t need to use refcount_t type for this counter,<br /> as its accessing is always protected under the sock lock.<br /> <br /> v1-&gt;v2:<br /> - add a check in sctp_sched_prio_set to avoid the possible prio_head<br /> refcnt overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sifive: Fix refcount leak in sifive_gpio_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.