ALT-PU-2023-8575-1
Package kernel-image-un-def updated to version 6.1.59-alt1 for branch p10 in task 332208.
Closed vulnerabilities
Modified: 2025-02-25
BDU:2024-07820
Уязвимость компонента nfc ядра операционной системы Linux, позволяющая нарушителю получить несанкционированный доступ к конфиденциальной информации в системе
Modified: 2025-10-24
BDU:2024-07821
Уязвимость компонента hub ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07822
Уязвимость компонента perf/x86/lbr ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-10-24
BDU:2024-07823
Уязвимость компонента powermate ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-08-19
BDU:2024-07826
Уязвимость компонента platform/x86 ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-07
BDU:2024-07832
Уязвимость компонента ravb ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2025-09-05
BDU:2024-07833
Уязвимость компонента nci ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07834
Уязвимость компонента x86/alternatives ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07835
Уязвимость компонента amdtee ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-11
BDU:2024-07838
Уязвимость компонента powerpc/47x ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-02-25
BDU:2024-07842
Уязвимость компонента mctp ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2024-11-11
BDU:2024-07847
Уязвимость компонента phy ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-11-11
BDU:2024-07851
Уязвимость компонента pinctrl ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2025-01-29
BDU:2024-08374
Уязвимость компонента ca8210 ядра операционной системы Linux, позволяющая нарушителю повысить свои привилегии
Modified: 2026-01-20
BDU:2025-03820
Уязвимость функции mana_poll_tx_cq() модуля drivers/net/ethernet/microsoft/mana/mana_en.c - драйвера поддержки сетевых адаптеров Ethernet Microsoft ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании.
Modified: 2025-10-24
BDU:2025-10573
Уязвимость функции hidpp_probe() модуля drivers/hid/hid-logitech-hidpp.c - драйвера подсистемы устройств пользовательского интерфейса ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
Modified: 2024-12-09
CVE-2023-52475
In the Linux kernel, the following vulnerability has been resolved: Input: powermate - fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
- https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46
- https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd
- https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b11f461bc
- https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc
- https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f
- https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9
- https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06
- https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8
- https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46
- https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd
- https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b11f461bc
- https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc
- https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f
- https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9
- https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06
- https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8
Modified: 2026-01-05
CVE-2023-52476
In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region.
- https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c
- https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265
- https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db
- https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c
- https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c
- https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265
- https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db
Modified: 2024-12-09
CVE-2023-52477
In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev->bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev->bos will be NULL and those accesses will result in a
crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1
- https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289
- https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c
- https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b
- https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3
- https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d
- https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81
- https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee
- https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81
- https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289
- https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c
- https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b
- https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3
- https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d
- https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81
- https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee
- https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81
Modified: 2025-01-10
CVE-2023-52478
In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated---
- https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1
- https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528
- https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c
- https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5
- https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b
- https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452
- https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e
- https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d
- https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1
- https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528
- https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c
- https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5
- https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b
- https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452
- https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e
- https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d
Modified: 2025-01-13
CVE-2023-52483
In the Linux kernel, the following vulnerability has been resolved:
mctp: perform route lookups under a RCU read-side lock
Our current route lookups (mctp_route_lookup and mctp_route_lookup_null)
traverse the net's route list without the RCU read lock held. This means
the route lookup is subject to preemption, resulting in an potential
grace period expiry, and so an eventual kfree() while we still have the
route pointer.
Add the proper read-side critical section locks around the route
lookups, preventing premption and a possible parallel kfree.
The remaining net->mctp.routes accesses are already under a
rcu_read_lock, or protected by the RTNL for updates.
Based on an analysis from Sili Luo
- https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a
- https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4
- https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c
- https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67
- https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a
- https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4
- https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c
- https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67
Modified: 2025-01-13
CVE-2023-52499
In the Linux kernel, the following vulnerability has been resolved:
powerpc/47x: Fix 47x syscall return crash
Eddie reported that newer kernels were crashing during boot on his 476
FSP2 system:
kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel instruction fetch
Faulting instruction address: 0xb7ee2000
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K FSP-2
Modules linked in:
CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1
Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2
NIP: b7ee2000 LR: 8c008000 CTR: 00000000
REGS: bffebd83 TRAP: 0400 Not tainted (6.1.55-d23900f.ppcnf-fs p2)
MSR: 00000030
- https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820
- https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746
- https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3
- https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14
- https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820
- https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746
- https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3
- https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14
Modified: 2025-03-19
CVE-2023-52502
In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn() Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF. Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock. nfc_llcp_sock_get_sn() has a similar problem. Finally nfc_llcp_recv_snl() needs to make sure the socket found by nfc_llcp_sock_from_sn() does not disappear.
- https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11ff058d93
- https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9
- https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d
- https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c
- https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8
- https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc
- https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a
- https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11ff058d93
- https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9
- https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d
- https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c
- https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8
- https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc
- https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a
Modified: 2024-12-10
CVE-2023-52503
In the Linux kernel, the following vulnerability has been resolved: tee: amdtee: fix use-after-free vulnerability in amdtee_close_session There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session); the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return 'sess' that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session. To fix this issue, treat decrement of sess->refcount and removal of 'sess' from session list in destroy_session() as a critical section, so that it is executed atomically.
- https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116
- https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce
- https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c
- https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27
- https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f
- https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116
- https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce
- https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c
- https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27
- https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f
Modified: 2024-12-11
CVE-2023-52504
In the Linux kernel, the following vulnerability has been resolved: x86/alternatives: Disable KASAN in apply_alternatives() Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine: BUG: KASAN: out-of-bounds in rcu_is_watching() Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0 ... __asan_load4() rcu_is_watching() trace_hardirqs_on() text_poke_early() apply_alternatives() ... On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled(). KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue. Fix it for real by disabling KASAN while the kernel is patching alternatives. [ mingo: updated the changelog ]
- https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae
- https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1
- https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b
- https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e
- https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4
- https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff8dacf61
- https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc
- https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae
- https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1
- https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b
- https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e
- https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4
- https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff8dacf61
- https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc
Modified: 2025-01-13
CVE-2023-52505
In the Linux kernel, the following vulnerability has been resolved: phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the "old" or for the "new" protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking. Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers.
- https://git.kernel.org/stable/c/139ad1143151a07be93bf741d4ea7c89e59f89ce
- https://git.kernel.org/stable/c/6f901f8448c6b25ed843796b114471d2a3fc5dfb
- https://git.kernel.org/stable/c/c2d7c79898b427d263c64a4841987eec131f2d4e
- https://git.kernel.org/stable/c/139ad1143151a07be93bf741d4ea7c89e59f89ce
- https://git.kernel.org/stable/c/6f901f8448c6b25ed843796b114471d2a3fc5dfb
- https://git.kernel.org/stable/c/c2d7c79898b427d263c64a4841987eec131f2d4e
Modified: 2025-01-13
CVE-2023-52507
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: assert requested protocol is valid The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesn't potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones.
- https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213
- https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53
- https://git.kernel.org/stable/c/354a6e707e29cb0c007176ee5b8db8be7bd2dee0
- https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c21521da
- https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848
- https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb
- https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802
- https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729
- https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213
- https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53
- https://git.kernel.org/stable/c/354a6e707e29cb0c007176ee5b8db8be7bd2dee0
- https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c21521da
- https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848
- https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb
- https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802
- https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729
Modified: 2024-12-11
CVE-2023-52509
In the Linux kernel, the following vulnerability has been resolved: ravb: Fix use-after-free issue in ravb_tx_timeout_work() The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work() is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout() ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called, netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop().
- https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705
- https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89
- https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6
- https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5
- https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965
- https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82
- https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705
- https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89
- https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6
- https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5
- https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965
- https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82
Modified: 2024-12-11
CVE-2023-52510
In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: Fix a potential UAF in ca8210_probe If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
- https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66
- https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add
- https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f
- https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e
- https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc
- https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f035415491640
- https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d
- https://git.kernel.org/stable/c/f990874b1c98fe8e57ee9385669f501822979258
- https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66
- https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add
- https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f
- https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e
- https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc
- https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f035415491640
- https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d
- https://git.kernel.org/stable/c/f990874b1c98fe8e57ee9385669f501822979258
Modified: 2025-03-19
CVE-2023-52512
In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: wpcm450: fix out of bounds write Write into 'pctrl->gpio_bank' happens before the check for GPIO index validity, so out of bounds write may happen. Found by Linux Verification Center (linuxtesting.org) with SVACE.
- https://git.kernel.org/stable/c/6c18c386fd13dbb3ff31a1086dabb526780d9bda
- https://git.kernel.org/stable/c/87d315a34133edcb29c4cadbf196ec6c30dfd47b
- https://git.kernel.org/stable/c/c9d7cac0fd27c74dd368e80dc4b5d0f9f2e13cf8
- https://git.kernel.org/stable/c/6c18c386fd13dbb3ff31a1086dabb526780d9bda
- https://git.kernel.org/stable/c/87d315a34133edcb29c4cadbf196ec6c30dfd47b
- https://git.kernel.org/stable/c/c9d7cac0fd27c74dd368e80dc4b5d0f9f2e13cf8
Modified: 2024-12-11
CVE-2023-52520
In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"), so it seems that the bug was copied from that driver. Compile-tested only.
- https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293
- https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81
- https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4
- https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106
- https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293
- https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81
- https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4
- https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106
Modified: 2025-01-16
CVE-2023-52532
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TX CQE error handling For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging.
- https://git.kernel.org/stable/c/a910e0f6304726da30a212feecec65cb97ff7a80
- https://git.kernel.org/stable/c/b2b000069a4c307b09548dc2243f31f3ca0eac9c
- https://git.kernel.org/stable/c/b67d7b1bfc46d05c1a58b172516454698e8d5004
- https://git.kernel.org/stable/c/a910e0f6304726da30a212feecec65cb97ff7a80
- https://git.kernel.org/stable/c/b2b000069a4c307b09548dc2243f31f3ca0eac9c
- https://git.kernel.org/stable/c/b67d7b1bfc46d05c1a58b172516454698e8d5004
