Ziyang Xuan

The issue is related to a potential data-race in the ` nft obj type get()` function in the `nf tables` component of the Linux kernel. This occurs because `nft unregister obj()` can run concurrently with ` nft obj type get()`, and there is no protection when iterating over the `nf tables objects` list in ` nft obj type get()`. This can lead to a potential data-race of the `nf tables objects` list entry. To resolve this, `list for each entry rcu()` is used to iterate over the `nf tables objects` list in ` nft obj type get()`, and `rcu read lock()` is used in the caller `nft obj type get()` to protect the entire type query process.

The issue is related to a potential data-race in the ` nft expr type get()` function, which can occur when `nft unregister expr()` is called concurrently. This may lead to a data-race condition when iterating over the `nf tables expressions` list. To address this, the function now uses `list for each entry rcu()` to iterate over the list and `rcu read lock()` in the caller `nft expr type get()` to protect the type query process. The vulnerability may impact the confidentiality, integrity, and availability of protected information.

The issue is related to a potential data-race in the ` nft flowtable type get()` function within the `nf tables` component of the Linux kernel. This occurs because `nft unregister flowtable type()` within `nf flow inet module exit()` can run concurrently with ` nft flowtable type get()` within `nf tables newflowtable()`, and there is no protection when iterating over the `nf tables flowtables` list in ` nft flowtable type get()`. To address this, the solution involves using `list for each entry rcu()` to iterate over the `nf tables flowtables` list in ` nft flowtable type get()` and using `rcu read lock()` in the caller `nft flowtable type get()` to protect the entire type query process.

The issue is related to a null pointer dereference error in the Linux kernel's team component when the team device type is changed from non-ether to ether. This occurs because the header ops of the team device are incorrectly changed to vlan header ops, triggering a null-ptr-deref for `vlan->real dev` in the `vlan dev hard header()` function. The error happens when a VLAN device is enslaved to a team device and the team device type is changed. To fix the bug, `eth header ops` should be cached in `team setup()` and then assigned to the `header ops` of the team net device when its type is changed.

A potential skb leak issue has been identified in the Linux kernel, specifically in the can327 feed frame to netdev() function. This issue occurs when the netdev is down, and the function fails to free the skb, leading to a leak. The problem is exacerbated by the fact that all callers of can327 feed frame to netdev() also fail to free the allocated skb. To fix this issue, the solution involves adding a kfree skb() call in can327 feed frame to netdev() when the netdev is down.

The issue is related to an out-of-bounds memory access flaw in the Linux kernel's TUN/TAP device driver functionality. This occurs when a user generates a malicious, overly large networking packet with napi frags enabled. The flaw can allow a local user to crash the system or potentially escalate their privileges, impacting the confidentiality, integrity, and availability of protected information.

A slab-out-of-bounds bug has been identified in the Linux kernel, specifically in the `decrypt internal` function within the `net/tls` module. The issue arises from a mismatch in memory size allocation for `tls ctx->rx.iv` when using AES128-CCM, where `tls set sw offload()` sets the size to 12, but `crypto aead ivsize()` returns a size of 16 for "ccm(aes)". This discrepancy triggers a slab-out-of-bounds bug when `memcpy()` attempts to read 16 bytes from a 12-byte memory space. The bug can be traced to the `decrypt internal+0x385/0xc40` function in the `tls` module.

The issue is related to a potential CAN frame reception race in the `isotp rcv()` function. When receiving a CAN frame, the current code logic does not consider concurrently receiving processes that do not show up in real-world usage. This can trigger `skb over panic()` in `skb put()`. The problem is fixed by adding a spin lock in `isotp rcv()` to ensure state changes and data structures stay consistent at CAN frame reception time.

A memory leak issue has been identified in the Linux kernel, specifically in the NFC digital module. The issue arises when the `digital send cmd()` function fails, causing the `params` variable to not be freed, resulting in a memory leak. This issue is resolved by freeing the `params` variable if `digital send cmd()` returns a failure.

A memory leak issue has been identified in the Linux kernel, specifically in the NFC digital component. The issue arises when `skb` is allocated in `digital in send sdd req()` but not freed when `digital in send cmd()` fails. This can cause a memory leak. The fix involves freeing `skb` if `digital in send cmd()` returns a failure.