CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52510 – ieee802154: ca8210: Fix a potential UAF in ca8210_probe
https://notcve.org/view.php?id=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/ded845a781a578dfb0b5b2c138e5a067aa3b1242 https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66 https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f03541 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52509 – ravb: Fix use-after-free issue in ravb_tx_timeout_work()
https://notcve.org/view.php?id=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/c156633f1353264634135dea86ffcae74f2122fc https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5 https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82 https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6 https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965 https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705 https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52508 – nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid()
https://notcve.org/view.php?id=CVE-2023-52508
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid() The nvme_fc_fcp_op structure describing an AEN operation is initialized with a null request structure pointer. An FC LLDD may make a call to nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation. Add validation of the request structure pointer before dereference. • https://git.kernel.org/stable/c/be90c9e29dd59b7d19a73297a1590ff3ec1d22ea https://git.kernel.org/stable/c/dd46b3ac7322baf3772b33b29726e94f98289db7 https://git.kernel.org/stable/c/8ae5b3a685dc59a8cf7ccfe0e850999ba9727a3c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52507 – nfc: nci: assert requested protocol is valid
https://notcve.org/view.php?id=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/6a2968aaf50c7a22fced77a5e24aa636281efca8 https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53 https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729 https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802 https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213 https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848 https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52506 – LoongArch: Set all reserved memblocks on Node#0 at initialization
https://notcve.org/view.php?id=CVE-2023-52506
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Set all reserved memblocks on Node#0 at initialization After commit 61167ad5fecdea ("mm: pass nid to reserve_bootmem_region()") we get a panic if DEFERRED_STRUCT_PAGE_INIT is enabled: [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000002b82, era == 90000000040e3f28, ra == 90000000040e3f18 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #733 [ 0.000000] pc 90000000040e3f28 ra 90000000040e3f18 tp 90000000046f4000 sp 90000000046f7c90 [ 0.000000] a0 0000000000000001 a1 0000000000200000 a2 0000000000000040 a3 90000000046f7ca0 [ 0.000000] a4 90000000046f7ca4 a5 0000000000000000 a6 90000000046f7c38 a7 0000000000000000 [ 0.000000] t0 0000000000000002 t1 9000000004b00ac8 t2 90000000040e3f18 t3 90000000040f0800 [ 0.000000] t4 00000000000f0000 t5 80000000ffffe07e t6 0000000000000003 t7 900000047fff5e20 [ 0.000000] t8 aaaaaaaaaaaaaaab u0 0000000000000018 s9 0000000000000000 s0 fffffefffe000000 [ 0.000000] s1 0000000000000000 s2 0000000000000080 s3 0000000000000040 s4 0000000000000000 [ 0.000000] s5 0000000000000000 s6 fffffefffe000000 s7 900000000470b740 s8 9000000004ad4000 [ 0.000000] ra: 90000000040e3f18 reserve_bootmem_region+0xec/0x21c [ 0.000000] ERA: 90000000040e3f28 reserve_bootmem_region+0xfc/0x21c [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010800 [PIL] (IS=11 ECode=1 EsubCode=0) [ 0.000000] BADV: 0000000000002b82 [ 0.000000] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 0000000000000000 9000000002eb5430 0000003a00000020 90000000045ccd00 [ 0.000000] 900000000470e000 90000000002c1918 0000000000000000 9000000004110780 [ 0.000000] 00000000fe6c0000 0000000480000000 9000000004b4e368 9000000004110748 [ 0.000000] 0000000000000000 900000000421ca84 9000000004620000 9000000004564970 [ 0.000000] 90000000046f7d78 9000000002cc9f70 90000000002c1918 900000000470e000 [ 0.000000] 9000000004564970 90000000040bc0e0 90000000046f7d78 0000000000000000 [ 0.000000] 0000000000004000 90000000045ccd00 0000000000000000 90000000002c1918 [ 0.000000] 90000000002c1900 900000000470b700 9000000004b4df78 9000000004620000 [ 0.000000] 90000000046200a8 90000000046200a8 0000000000000000 9000000004218b2c [ 0.000000] 9000000004270008 0000000000000001 0000000000000000 90000000045ccd00 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<90000000040e3f28>] reserve_bootmem_region+0xfc/0x21c [ 0.000000] [<900000000421ca84>] memblock_free_all+0x114/0x350 [ 0.000000] [<9000000004218b2c>] mm_core_init+0x138/0x3cc [ 0.000000] [<9000000004200e38>] start_kernel+0x488/0x7a4 [ 0.000000] [<90000000040df0d8>] kernel_entry+0xd8/0xdc [ 0.000000] [ 0.000000] Code: 02eb21ad 00410f4c 380c31ac <262b818d> 6800b70d 02c1c196 0015001c 57fe4bb1 260002cd The reason is early memblock_reserve() in memblock_init() set node id to MAX_NUMNODES, making NODE_DATA(nid) a NULL dereference in the call chain reserve_bootmem_region() -> init_reserved_page(). After memblock_init(), those late calls of memblock_reserve() operate on subregions of memblock .memory regions. As a result, these reserved regions will be set to the correct node at the first iteration of memmap_init_reserved_pages(). So set all reserved memblocks on Node#0 at initialization can avoid this panic. • https://git.kernel.org/stable/c/f105e893a8edd48bdf4bef9fef845a9ff402f737 https://git.kernel.org/stable/c/19878758accf6b2788091a771d9f9fee7bab11ab https://git.kernel.org/stable/c/b795fb9f5861ee256070d59e33130980a01fadd7 •