CVE-2023-52906 – net/sched: act_mpls: Fix warning during failed attribute validation
https://notcve.org/view.php?id=CVE-2023-52906
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mpls: Fix warning during failed attribute validation The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid combination according to the comment above 'struct nla_policy': " Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN: NLA_BINARY Validation function called for the attribute. All other Unused - but note that it's a union " This can trigger the warning [1] in nla_get_range_unsigned() when validation of the attribute fails. Despite being of 'NLA_U32' type, the associated 'min'/'max' fields in the policy are negative as they are aliased by the 'validate' field. Fix by changing the attribute type to 'NLA_BINARY' which is consistent with the above comment and all other users of NLA_POLICY_VALIDATE_FN(). As a result, move the length validation to the validation function. No regressions in MPLS tests: # ./tdc.py -f tc-tests/actions/mpls.json [...] # echo $? 0 [1] WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118 nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117 Modules linked in: CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117 [...] Call Trace: <TASK> __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline] netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x38f/0x500 net/socket.c:2482 ___sys_sendmsg net/socket.c:2536 [inline] __sys_sendmsg+0x197/0x230 net/socket.c:2565 __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd • https://git.kernel.org/stable/c/2a2ea50870baa3fb4de0872c5b60828138654ca7 https://git.kernel.org/stable/c/2b157c3c5d6b8ddca48d53c9e662032f65af8d61 https://git.kernel.org/stable/c/453277feb41c2235cf2c0de9209eef962c401457 https://git.kernel.org/stable/c/9e2c38827cdc6fdd3bb375c8607fc04d289756f9 https://git.kernel.org/stable/c/8a97b544b98e44f596219ebb290fd2ba2fd5d644 https://git.kernel.org/stable/c/9e17f99220d111ea031b44153fdfe364b0024ff2 •
CVE-2023-52905 – octeontx2-pf: Fix resource leakage in VF driver unbind
https://notcve.org/view.php?id=CVE-2023-52905
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix resource leakage in VF driver unbind resources allocated like mcam entries to support the Ntuple feature and hash tables for the tc feature are not getting freed in driver unbind. This patch fixes the issue. • https://git.kernel.org/stable/c/2da48943274712fc3204089d9a97078350765635 https://git.kernel.org/stable/c/c8ca0ad10df08ea36bcac1288062d567d22604c9 https://git.kernel.org/stable/c/53da7aec32982f5ee775b69dce06d63992ce4af3 •
CVE-2023-52904 – ALSA: usb-audio: Fix possible NULL pointer dereference in snd_usb_pcm_has_fixed_rate()
https://notcve.org/view.php?id=CVE-2023-52904
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix possible NULL pointer dereference in snd_usb_pcm_has_fixed_rate() The subs function argument may be NULL, so do not use it before the NULL check. • https://git.kernel.org/stable/c/bfd36b1d1869859af7ba94dc95ec05e74f40d0b7 https://git.kernel.org/stable/c/f57204edc10760c935d8d36ea999dc8acf018030 https://git.kernel.org/stable/c/a474d4ad59cd4642d1b7e3a6c08cef9eca0992c8 https://git.kernel.org/stable/c/92a9c0ad86d47ff4cce899012e355c400f02cfb8 •
CVE-2023-52903 – io_uring: lock overflowing for IOPOLL
https://notcve.org/view.php?id=CVE-2023-52903
In the Linux kernel, the following vulnerability has been resolved: io_uring: lock overflowing for IOPOLL syzbot reports an issue with overflow filling for IOPOLL: WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: events_unbound io_ring_exit_work Call trace: io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773 io_fill_cqe_req io_uring/io_uring.h:168 [inline] io_do_iopoll+0x474/0x62c io_uring/rw.c:1065 io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513 io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056 io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 worker_thread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863 There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which __io_cqring_overflow_flush() happens from the CQ waiting path. • https://git.kernel.org/stable/c/de77faee280163ff03b7ab64af6c9d779a43d4c4 https://git.kernel.org/stable/c/ed4629d1e968359fbb91d0a3780b1e86a2c08845 https://git.kernel.org/stable/c/7fc3990dad04a677606337ebc61964094d6cb41b https://git.kernel.org/stable/c/544d163d659d45a206d8929370d5a2984e546cb7 •
CVE-2023-52901 – usb: xhci: Check endpoint is valid before dereferencing it
https://notcve.org/view.php?id=CVE-2023-52901
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Check endpoint is valid before dereferencing it When the host controller is not responding, all URBs queued to all endpoints need to be killed. This can cause a kernel panic if we dereference an invalid endpoint. Fix this by using xhci_get_virt_ep() helper to find the endpoint and checking if the endpoint is valid before dereferencing it. [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8 [233311.853964] pc : xhci_hc_died+0x10c/0x270 [233311.853971] lr : xhci_hc_died+0x1ac/0x270 [233311.854077] Call trace: [233311.854085] xhci_hc_died+0x10c/0x270 [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4 [233311.854105] call_timer_fn+0x50/0x2d4 [233311.854112] expire_timers+0xac/0x2e4 [233311.854118] run_timer_softirq+0x300/0xabc [233311.854127] __do_softirq+0x148/0x528 [233311.854135] irq_exit+0x194/0x1a8 [233311.854143] __handle_domain_irq+0x164/0x1d0 [233311.854149] gic_handle_irq.22273+0x10c/0x188 [233311.854156] el1_irq+0xfc/0x1a8 [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm] [233311.854185] cpuidle_enter_state+0x1f0/0x764 [233311.854194] do_idle+0x594/0x6ac [233311.854201] cpu_startup_entry+0x7c/0x80 [233311.854209] secondary_start_kernel+0x170/0x198 • https://git.kernel.org/stable/c/50e8725e7c429701e530439013f9681e1fa36b5d https://git.kernel.org/stable/c/375be2dd61a072f7b1cac9b17eea59e07b58db3a https://git.kernel.org/stable/c/2d2820d5f375563690c96e60676855205abfb7f5 https://git.kernel.org/stable/c/9891e5c73cab3fd9ed532dc50e9799e55e974766 https://git.kernel.org/stable/c/66fc1600855c05c4ba4e997184c91cf298e0405c https://git.kernel.org/stable/c/f39c813af0b64f44af94e435c07bfa1ddc2575f5 https://git.kernel.org/stable/c/08864dc14a6803f0377ca77b9740b26db30c020f https://git.kernel.org/stable/c/e8fb5bc76eb86437ab87002d4a36d6da0 •